Products should start with what you want to learn, not what you want to build.

I’ve spoken to a lot of startups and big companies over the last couple of years, and I find myself giving similar feedback. So it made sense to begin to write this feedback down. I’ve made this mistake many times in the past myself.

The first steps into exploring a product idea can be a messy process. Lots of ideas will change and evolve as the product develops, and we learn what’s driving the desired effect. We’re building the plane while falling to earth, with no books on aerodynamics… only the wind rushing past us!

When defining the very first version of your product, it’s natural to be extremely focused on building and delivering the very first version. Getting it in front of users at scale as quickly as possible so you can start tapping into that sweet, sweet feedback is hugely valuable. It makes sense to optimise your process around getting the product out there.

This is the essence of the Build, Measure, Learn approach popularised by Lean

1. Based on what we know, build something that we think solves the problem
2. Measure its effectiveness
3. Bask in the glory of knowledge as people start to use the product!
4. Go to 1

Many people interpret this ‘building’ part as the primary goal, and that the build needs to be a reasonably functional product. It’s not a bad suggestion, getting your product in front of a wide audience uncomfortably early is a great way to discover what’s working. Having something real closes the feedback loop ready for the next iteration, arming us with lists of things to improve.

The major failure point I often see here is when teams haven’t spent enough time determining how the core structure of the product leads to the effect they desire and commit to a core structure too early.

By committing to a first build, they limit their opportunity for learning and will have to do a large amount of work to try an alternative approach (often Re-structuring large parts of the product or even pivoting their entire approach).

Yes, the code can change quickly, and ideas will evolve as we learn, but being as pragmatic as possible with what we’re building in the first place can save ourselves a huge amount of time. We want to make sure we end up with something that actually works… remember, we’re falling to earth quickly, but we need to make sure we take flight!

Where things can go wrong…

Let’s look at an example of where this can cause a problem, then let’s see how this can be improved.

Let’s suppose that we’re aiming to build a marketplace product that connects software companies to software contractors (this is a real-world example, but the product is changed slightly to protect the company).

When building this marketplace, one of the teams’ core goals is to enable companies to connect with contractors and book them for software development.

It’s easy to imagine this functionality, and possibly easy to implement. We can design a flow for companies to create their requests for a contractor, and for contractors to apply for this request. Great.

But would it be better to have the companies look through a list of contractors and choose people they want to book? Or would it be better for contractors to apply for the positions in the companies that need their services? These two flows seem simple on the surface, but to get to a minimum viable product, many different UI flows will need to be made to support either approach. This is a critical fork in the road.

Often I see teams go with some early research from both audiences and choose what feels right, commit to an approach, then test it at launch. That’s what happened in this case.

The team speaks to contractors. They learn that they want to be able to choose a company to work for.

The team speaks to companies. They learn companies want the power of choice and choose a contractor to work for them.

The team goes ahead and prototypes this flow, with the companies posting their vacancies, and contractors choosing a vacancy. In the last step, the company who posted the vacancy decides which contractor gets the role.

In prototype testing it seems to go well, people give positive feedback from the companies they tested with, and contractors respond well to the listings and application, pointing out how easy it was for them to get set up.

Sounds promising! The team knuckle down and get this built. They launch the product, and hope to see companies begin to list openings, and contractors applying for the shiny new openings!

To get things moving, they begin spending a small fortune on Facebook advertising to bring people to the top of the funnel.

Their UX design is great, and some companies start posting ads, and some contractors begin applying, but growth is slow, and they’re spending a lot of money on Facebook ads!

In early feedback post-launch, an unexpected by-product of their products design is that contractors aren’t coming back to the site after they’ve seen the currently available listings. Great! Some learning. So, they create an email service that sends out new opportunities to contractors. This helps get some of these contractors coming back, but a lot of people begin unsubscribing from the emails because they’ve now either got a contract or those contracts aren’t as relevant as they wanted, or companies aren’t choosing that contractor and it feels like wasted time.

At this point, the team is so wedded to the current model of companies posting listings, and contractors applying to them that drastic changes to the application structure are difficult to commit to. Perhaps they should have gone with the option of letting contractors create a profile, list their availability, and have companies contact them directly? They could have handled payment through the product too. Would that have helped them have better retention?

This way there might have been less noise generated from the constant emails… but contractors had told them they wanted to choose a company!

The team now has to make a very difficult choice of completely re-thinking their model to try something that could be better, and potentially put their current model on hold.

So, how could this have been different?

The team was so focused on building an initial version of the product that they didn’t break down everything they wanted to learn and deferred most of this until after initial launch. This made it very hard for them to commit to trying something drastically different that could have created a stronger marketplace ecosystem.

Let’s think back to the Build, Measure, Learn cycle. It works great for testing assumptions, but it also requires that the team understands that they should only be building what they aim to learn! They do not need to build out their product end to end, nor do they need to focus on launching a minimum viable product until they’ve tried a few approaches to find the path of least resistance, and what drives the strongest network effect.

Building the first version of your product on a poor model can make it hard to move away from this at a later date.

So, my suggestion to early-stage teams is to reverse the process:

1. Start with what you want to learn
2. Determine how you can measure this
3. What’s the minimum you can build to achieve this learning

Let’s try this…

So, let’s imagine we’re right back at the start of the marketplace product we talked about earlier.

This time, the team asks themselves ‘what do we want to learn?’

They come up with a whole list of things to learn, among them are:

• What do companies need from a contractor?
• What keeps companies engaged in a marketplace?
• What keeps contractors coming back?
• What annoys contractors about the way they currently find work?

By having the team focus on what they need to learn, they can instead design experiments and prototypes that will drive a stronger fundamental model, rather than having to backtrack later on.

If you spend time with any of the Lean books by Jeff Gothelf you’ll see that this is the core of his methodology; That you need to focus on the learning, and optimise for that rather than holding on to your core assumptions.

Early on, build only what you need to learn, some core decisions are hard to move away from.

TLDR

Don’t Build, Measure, Learn. Start with what you want to learn, work out how you’ll measure it, then build for that.

Optimise for flexibility early on, and try other approaches. Focus on outcomes, not your methods.

Stop falling in love with your ideas. Fall in love with the outcome.