How to build something you’ve never built

Hi Reader,

You know that feeling of “you don’t know what you don’t know”?

You get it always when you start building a new system or a complex feature. And you’re just thinking: how are we supposed to know how to build this if we’ve never built it before?

As someone who likes to control things (yes, that’s me), I tried my best to find an answer.

Animation Magnify GIF by POKÉMON Detective Pikachu

Of course, very predictably, there is no answer. We can’t predict many of the technical issues that will come our way.

But that doesn’t mean we should just wing it.

What helps is spending time on proper technical discovery and design. When you do it well, you cover the main principles and make the main decisions that orient you during the build.

So I created a framework for it. Selfishly, to help me. And to help you make sure you don’t miss the important questions.

If you want to get excellent at technical discovery and design, and remove the stress of building without knowing if it will work, this issue is for you.

Today in 10 minutes you will:

Get an overview of the framework
How to use it
Download the framework with each step, considerations, questions, and an example

Why should PMs care?

This framework will help you if you’re starting a new development, and:

→ You don’t know how to map it out technically

→ You don’t know everything you need to consider

→ You’re worried you’ll miss something that creates huge delays and escalations

→ You might not even know which questions to ask your engineers

I know that feeling very well.

The first time I built a product from scratch, the first question I faced was: where do I even deploy it? I had no idea what my options were, what the trade-offs were, or what to consider.

I ended up using an on-prem server, which required lots of change management. Only later did I find out we would have to migrate to the cloud anyway, because it meant less maintenance work for us and better ops support.

The framework

The framework is simple. It’s a map of every technical area you need to think through when you build something new.

You start at the bottom with infrastructure and work your way up to the UI.

Six layers, from the bottom up:

→ Infrastructure and environments. Where your product runs.

→ Data. What data you need, where it lives and who owns it.

→ Backend and business logic. The services and rules that make it do what it promises.

→ Integrations and APIs. Every connection to other systems.

→ Application and client layer. The software people actually run, and on which devices.

→ UI and experience. What users see and touch, including when things go wrong.

Three more things run through every layer: security, delivery and operations. Think of them as the spine of the pyramid.

You don’t deal with them once at the end. You ask about them at every level.

How do you actually use the framework?

You go layer by layer, from infrastructure up to the UI. Each layer has questions you have to work through, and a worked example you can use for inspiration.

To answer the questions, you can research, ask engineering and, best of all, set up a workshop where you work through the questions and decisions together. The aim is to surface the big technical decisions, uncertainties and potential showstoppers.

Why I think this works

It gives you a structure. Instead of hoping you remember everything, you walk through the layers one by one. Nothing gets skipped because it felt obvious.

It gives you the questions. You don’t need to the most technical person in the room. You need to know what to ask. Most of the time, the problem isn’t that nobody has the answer. It’s that nobody remembered to ask the question early enough.

It brings the nasty surprises forward. The environment that takes weeks to provision. The other team’s roadmap you depend on. The security review that starts too late. These can block you for months, as I learned on my first product.

With the pyramid, you find them in discovery, not halfway through the build.

Will it predict everything? No.

But you start building knowing what is solved and what is still open. That is a very different feeling.