The 'right' way to build a product

* This is a comprehensive summary of Roger Norton's article. [Summarised by Ighlaas Carlie].

‍

What is the 'right' way to build a product?

‍

‍

I often see images of the above shared in product groups when questions arise about the “right” way to build new products. But there is no single “right” way to build a new product. Founders that we work with often start with the expectation that there is a single “right” way to launch a product. In practice, the answer is usually “it depends”.

Simply put, there is no single “right” way to build a new product. There are many different approaches, and they all have a place. Below, I unpack some of the pros and cons of some approaches to unpack when you might want to use them.

‍

R&D Approach

Sometimes, if you’re trying to build something complicated or very technical, you normally want to build out the core building blocks or mechanics first. If what you are building is very technical and likely IP-driven, this will probably be your approach.

An example of this is the iPhone, where they started by analysing and inventing a new way to interact with your device as well as the layout of the elements that you interact with. They then focused on the form factor, then the internal circuitry, and so on — each step requiring focus and design. A similar approach is needed for a vaccine, where initially, the delivery mechanism is researched and discovered. Then the best delivery agent, then the testing for frequency and cover degradation, then infrastructure rollout and manufacturing processes, etc.

In short, the R&D Approach is the preferred way to build new, very technical things. However, this approach requires a lot of funding up-front, and you get very little market feedback until right at the end. So, it’s not a great way to build that new consumer-focused savings app you’ve been thinking of.

‍

Problem-focused approach

The second way to approach building a new product is to be relentlessly focused on the problem that you’re solving for customers. In this image, you’re helping customers get from point A to point B faster. You ship the simplest version, take their feedback and design the next iteration. Rinse, repeat. Build, Measure, and Learn.

Twitter first launched as a group SMS platform where you could send an update SMS to your followers. (It’s also where the character limit for tweets came from.) They then iterated and iterated until you have what it is today. Facebook started out as a Hot-or-Not to “connect” people on your campus. Then it became an online yearbook. Then a personal page where you could poke and later message each other. Today, Facebook’s product is a completely different way to solve the initial user’s problem.

The beauty of building this way is that you might get to step 2 and hear that your customers want a tandem bike, not a faster one. Then a minibus, then a bus system. By being Problem-focused, you can iterate your way to a solution that you could not have imagined at the beginning. (I’ve written on this before.)

‍

MVP approach

In the Minimum Viable Product (MVP) approach, you build the absolute simplest version of your solution and ship it to customers. It’s normally a “shitty” version that “you should be embarrassed by.” The catch is that it still needs to actually solve the fundamental problem that your customer has, regardless of quality. Over time, you clean it up, improve it, add to it and make it generally better. Hopefully.

WhatsApp fundamentally still deliver what their very first version did. They’ve added things–expanded functionality, made it more secure and easier to use–but fundamentally you can still create messages and groups.

‍

The benefit of the MVP approach is the evidence that if users are willing to use a ‘slimmed down’ version of the solution with a poor user experience, then you’re probably addressing a big pain point for them. The drawback is that you often get so fixated on just building better versions of the product you have in your mind that you dismiss feedback that doesn’t support it, and can miss huge adjacent opportunities to solve.

Semantically, any of the first steps in these processes could be considered an MVP in certain contexts… just to get extra confusing!

There are also many other ways to build a new product. Each with its own benefits and use cases. In my experience, it’s often more effective to be ‘problem-focused’ and double down on the customer feedback to guide you. If you’ve started in a good place, then in hindsight, it might look more like the MVP approach where the final product isn’t that different. Yet, starting with blinkers on and using an MVP approach without catering for feedback and pivots is always a sure way to fail.

‍

I love this alternative take by Dorian Taylor:

“[Building] software isn’t like a car at all: if anything, it’s more like a university campus, where different buildings are complete artefacts in their own right but loosely coupled together to form a unified service. It is perfectly reasonable for some parts to be undergoing construction while others are being planned. Taken as a whole at any given moment, some parts of the system will have more detail and others will have less.”

I believe the key is to know the benefits of different approaches and to intentionally choose the one that will be most effective in your situation.

‍

‍

‍

‍

‍

‍