When creating a new product, we usually do research, write specs, draw sketches and diagrams, and a long etcetera of activities for finding the right shape.

However, there is a cap on how far we can go with these tools. When we work on paper —either physical or virtual—, we’re working in the abstract terrain of ideas.

It’s hard, if not impossible, to visualize everything upfront. There are always blind spots, hard to anticipate unknowns that will remain. From hidden consumer goals that haven’t still emerged to technical constraints we cannot predict, many are the subtleties that reality holds for us.

There is a moment when we feel our understanding stagnates, and we need to move into the concrete. We need to see the thing, working in the real world, to keep moving the needle further.

So what should we do then? Should we go all-in to build the actual product?

A Cheaper Option.

I’m currently collaborating on a new SaaS product to help people relocate between countries, and recently we faced that very same situation. It’s a multi-sided system with different actors involved, and this time, concretely, we were working on the lawyers’ side, the people managing the procedures.

We had a design, but there were still gaps in our understanding, things we needed to learn by building. Developing the real product and getting our hands into code was tempting. But we didn’t. Instead, we built a spreadsheets-based prototype. And we’re glad we did.

In just a few days, we built a fully working tool that, among other things, can manage customers, products, pricing, discounts, quotes, contracts, invoices, and settings.

Sheets’ color tags identify scopes, visually grouping tightly-related features and delimiting the boundaries between the different sub-contexts that make up the solution —again, customers, catalog, pricing, discounts, actions, quotes, billing, etc.

Prefixes on sheets names identify commands ([C]) and queries ([Q]).

In commands sheets ([C]), white-background cells represent input fields.

Grey-background cells contain read-only information and provide immediate feedback to the user about what they’re inserting.

Both query sheets ([Q]) and read-only cells in command sheets ([C]) are protected (🔒), so other non-admin users cannot accidentally modify them.

As you can see, a quick prototype like this gave us a strategic view of the different components making up the system and how they relate to one another to work as a whole.

And the best of all: it’s served us to iterate fast and anticipate crucial flaws that would have been dramatically more costly to catch further down the process.

Harness the Power of the Spreadsheet.

I’ve been using spreadsheets to prototype for years, and It’s incredible how powerful they are for molding solution concepts, exploring problems, finding gaps, and grasping the domain better before moving further —everything through real-world use, in its real environment.

Are they useful for everything? Obviously not, but they can be perfect in forgiving environments where the user doesn’t need much guidance from the UI to start making meaningful progress.

And even then, if a more guided UI is needed, that’s not the end. We can still build a no-code layer on top of them (e.g., via Google App Sheets) to turn them into real apps. I still haven’t got my hands into it, but looks very promising.

And if that wasn’t enough, we can connect with things like Google Apps Script to implement custom JS code running in the cloud for more complex logic.

I didn’t use it specifically for this project, but I did it in the past for other initiatives. Indeed, potent stuff.

Use the Best Tool at Hand.

Prototyping does not end in spreadsheets.

There are many other ways to quickly prototype. We’re living the ascent of no-code/low-code tools, and it’s incredible the type of things we can build on top of them. If there are other instruments that you know best and can do the job well enough, use them.

And if you don’t know of any, you’d do well in learning and integrating no-code/low-code into your toolset.

Remember, this is a means for learning, not for perfection.

Make it Real.

Consumer research and design over paper can only bring you forward up to some point. Once there, you need to see the solution. You need to touch it. And you need to test it in the real world to fill in gaps in your understanding.

To do so, you have two options: go all into building the final solution or use a proxy/prototype instead.

Guess what’s more sustainable.

The first one delays feedback for too long and can be dramatically costly, even ruin you, before finding context/form fit.

The second shortens the feedback loop and helps you involve the user in the process, uncover unknowns earlier, and evolve more quickly.

So pick wisely.

Uncover unknowns first. Prototype before building the real thing.

---

Say it out loud. Is there anything you disagree with? Anything missing that you’d like to add? If so, I’d love to hear your thoughts so, please, leave them in the comments.

Get on board. Do you want to receive more content like this right in your inbox? You can sign up for the newsletter here or in the form below 👇.

Share it. Do you think someone you know may enjoy this post too? If so, please forward it to them.

Have a creative time.