Idea-Miracle-Launch is not a good strategy. Here’s what to do instead.

Take your idea through research, build, launch and measure in a sustainable way.

When I worked in “stealth mode” on my news startup, I assumed what customers wanted. I planned for a grand launch. I expected people to knock on my virtual door asking to use the product.

But hope was never a good launch strategy.

We released the first version of our product to the sound of crickets. We marketed hard, and brought along a few reluctant customers to our site. They didn’t stick around. They certainly didn’t visit again.

It was only later we realised how relevant lean methodologies (and product management) are to running a startup.

Lean startup is so popular in tech, it runs the risk of being mistaken for a fad. I assumed I knew what “lean” meant — it’s about building-measuring-learning, right? — and that I was following it. Just because I was learning a lot about the industry didn’t mean I was learning about my business though.

Credit: Allie Brosh, Hyperbole and a Half

It was hard for me to start thinking of creating products as an analytic learning process, rather than a creative process that started with the spark of an idea and ended in a unicorn.

-

The following is a process I cobbled together by observing the works of others. The goal here is not to scale, it’s to systematically learn what it takes to create a product and viable business. It is not the only process out there, neither is it universally applicable. It helped me get started, and maybe it can be modified to suit the needs of another business also.

Where to start

In the first year of my startup, we spent a lot of time learning to code, design, write copy.

Starting at the “build” stage of “build-measure-learn” was engrossing. Our team of engineers and MBAs got busy planning, building and polishing the first version of our product in a safe space, free from feedback and critique from “outsiders”.

But we were shutting out customers too. This not only meant that the product we built was useful to no one, but that we had wasted the limited resources available to us, time capital and opportunity.

Here, it would really have helped to start by speaking to customers. The qualitative data generated forms the basis for:

• having an understanding, not assumptions, of customers’ problems
• knowing whether they’re actively or subconsciously looking for solutions
• noting what words they use to describe their limitations

There is no better driver for decisions on whether to build, what product decisions to make, how to market, and so on.

In the iterative process, perhaps it’s better to start with “Learn”.

Learn

Let’s assume you want to create a product in the cleaning industry. It’s great to start by researching the industry online — who are service providers, what solutions do they offer, who are their customers — and draw some problem hypotheses. Perhaps you feel these problems acutely yourself.

It’s imperative to test these hypotheses though, and there’s no better way to do so than to speak directly to customers and experience first-hand the inefficiencies of service providers. This is precisely what Homejoy’s adora cheung did.

Brainstorm various narrow customer segments of people you’d like to interview. Broad segments like “everyone”, “millennials”, “friends” are meaningless and don’t count.

Customer Development guru Cindy Alvarez recommends that your first customers meet the following criteria:

• Market Size: how large is the well-defined, niche market they belong to?
• Severity of Pain: is the problem they’re experiencing so severe that your product is a painkiller, not a vitamin?
• Ability to Change: are they likely to adopt a new solution early?

Based on my experience, I would add this criteria:

• Ability to Pay: how likely are they to pay for a solution?

This means that your early customers should ideally be at the intersection of this Venn Diagram:

One way to prioritise what customer segments to interview first is by using a modification of Justin Wilcox’s SPA treatment.

• Enter the 4 criteria from the venn diagram into a column in a spreadsheet
• List out your customer segments in the top row
• Give each customer segment a score from 1–3 (1 being lowest, 3 highest) for these criteria. Estimates are fine here.
• Multiply to get the results. The segment with the highest score can be interviewed first.

This exercise shouldn’t take more than an hour to do. This is a quick example applied to the cleaning industry. My customer segments are vaguely defined still, but I have a fairly good idea that I should speak to working parents first.

I realise this sounds like a tedious process, but it’s only necessary to interview about 5 people per customer segment before you start to see trends in their problems and behaviour.

Justin Wilcox has a brilliant tutorial on how to conduct these interviews to eliminate bias and prompt an interviewee to share: available here. The goal is not to lead the conversation to your product idea, but to listen intently to their problems.

Mike Fishbein and Charles Liu provide lists of good questions to ask here and here respectively.

Upon conducting interviews, one of three things will happen:

• you’ll find you need to revise and narrow customer segments you’d identified, and reiterate this process,
• you’ll fill the table with far better estimates, identify a customer segment you can serve and conduct more interviews within it,
• you’ll realise this is all for nought, and move on to the next problem hypotheses or industry to build in.

Assuming it’s option 2, let’s move on to the build process!

Build

It’s not easy to decide what ought to constitute a Minimum Viable Product. Paul Graham recommends releasing an MVP “early and often”, while Joel Spolsky waits to launch until it “doesn’t completely suck”.

But there’s no metric for how much something sucks but the opinion of a customer.

As David J Bland writes, perhaps one of the hardest things “about Minimum Viable Products is that while you decide what’s Minimum, the customer determines if it is Viable.”

This means that the MVP is essentially a tool for testing at low risk the assumptions you made about what users want.

This is far less daunting to tackle after going through a round of customer development. Justin Wilcox has a fantastic post on a process to consolidate the efforts of customer development and discover the specific pain points they experience in relation to the problem.

The techniques of taking a product from that concept stage, to build, release and revision are covered by traditional product management.

Below is a quick primer on some techniques that can guide the decision of what to build, whether that’s a landing page to capture interest like Buffer did, or later, a more involved prototype like Dropbox did. These are meant to clarify your thought process and get your team on the same page.

1: Requirements Writing

Why use it: to clarify to the team what success looks like for your product and how to achieve it.

There are three types of requirements:

• operational, or “what do we want to achieve”
• functional, or “what do we need in order to achieve it”
• non-functional, or “what constraints can we expect”

In operational requirements, state what you’re trying to accomplish with this design and why: “to aid <members of this customer segment> with <this problem> by <creating this solution>”. This information is derived from the greatest pain point you identified in the previous exercise.

If you were creating a news product, an operational requirement could be:
“- To aid career-focused young women stay informed on general news.
- To convey news in a way that integrates with their existing reading habits and routines.”

Functional requirements are everything your product needs to do (features, tasks), while non-functional are the implementation and performance constraints to expect. These can be covered by user stories.

2: User Stories

Why use it: to define requirements from the perspective of the user.

The value of this agile software technique is that it clarifies for your team:

• why a feature is valuable to the user from their perspective,
• what that feature should look like,
• when that feature is considered complete and ready to ship.

Simply put, the format of a user story is this:
a. As a <type of user>, I want <some goal> so that <some reason>.
b. Followed by “acceptance criteria” with the criteria for shipping the feature.

Every feature and function for the potential solution is described in this format on a separate card.

2a. As a <type of user>…

The trouble with a user story is when it’s too vague. Let’s go back to the example of the news product. A user story for that could be:
“As a news consumer, I want to get news on my phone so that I can be informed”
This is terribly done though. The general goal of the news product has been conveyed by the operational requirement already, so this user story doesn’t clarify what features to consider and why.

Here you can start to match the pain points found during customer development with specific feature ideas.

So, for a news product, I might realise that my target user wants:
- news presented such that they understand it in five minutes flat,
- the ability to read in the subway when there’s no wifi
- etc.

A feature I could design based on this is a “Save for Later” option that allows the user to download an article and read it offline. A user story for this:
“As a news consumer, I want to store news articles offline so that I can read them during my commute”

2b. Acceptance Criteria

An acceptance criteria is the behaviour that the product should be able to exhibit before it’s considered ready.

So, an acceptance criteria in this example could be: “When I browse through my news feed, then I want a “Save” option for every story”.

Joanna Beltowska of Pivotal Labs has an excellent post on how to write well-defined user stories available here.

3: Prioritisation Axes

Why use it: to make decisions on what user story to work on first and next.

For any solution, there are several user stories that you’ll come up with. There has to be a way to decide which of those to build with the time and manpower constraints.

I find that the easiest and quickest way to prioritise user stories for a product I’m building is to take place them on a chart.

There are two charts you could consider:

3a: Impact vs. Effort
This chart is great to use particularly for the first few iterations of the MVP; what user stories are essential to help accomplish the goal as stated in your operational requirement?

3b: Important vs. Urgent
This variation, called the Eisenhower method, is great to use when time is the greatest concern.

-

Through the many iterations of the “learn-build-measure” cycle, this process can be applied whether you’re designing landing pages, rudimentary prototypes, or a full product that’s post product-market fit.

Measure

There are vanity metrics — monthly uniques, page views, downloads — but the success of the MVP is not defined by them. In the first iteration of our news product, metrics were an afterthought. We cared about “having” users on our site and “getting” them to read one news story on our site.

In the first iteration after we adopted a lean system, we cared about listening directly from our users, and measuring information retention.

One of those strategies helped us improve our product.

Dave McClure created the AARRR System: Startup Metrics for Pirates, in which you pick the metrics by which to define success for your product in these categories — acquisition, activation, retention, referral, revenue.

Adapted from the work of Dave McClure, David J Bland, Ash Maurya and Brant Cooper

While quantitative data can tell you what happened, qualitative data tells you why.

Interview everybody: a person who signs up at your landing page, shares your product, strangers who you wished were doing these things. From this, and from watching them use your product, you’ll know exactly why it isn’t working (and it is never working in the first few iterations).

500 Startups’ pivot pyramid shows the various considerations for a startup. I would add one more rung to it, particularly if your product is paid from the start, “Revenue” alongside “Growth”.

Consider adding a “Revenue” stack next to or above “Growth”.

The pivots you could make:

• Customer Pivot: You found that the problem you’re solving is felt acutely by a different customer segment. Do a Customer Pivot. Don’t forget to reconsider all that relies on a strong foundation: problem, solution, etc.
• Problem Pivot: You’ve found a customer segment you can serve, but discovered that the problem you were solving isn’t the one they feel most acutely. Do a Problem Pivot and reconsider solution, tech, growth decisions.
• -
• Solution Pivot: You know your customer and their problem, but your solution isn’t good enough. Pivot here and reconsider tech, growth, revenue strategies.
• Tech, Growth, Revenue Pivots: It is not very likely that you’ll require a pivot in these areas until you find product-market. If you’re testing assumptions you made on whether you’d be able to generate revenue for instance, first ensure that the foundation of Customer, Problem, Solution are solid. Then, Pivot as necessary.

Finally..

Startups are something of a modern day fairytale. Once upon a time, a young engineer chanced upon a minimum viable pumpkin, and was whisked away to the investors ball.

The reality is a lot different to the mythology surrounding it. More than anything, a startup is an exercise in what it takes to design a product people want and to create a sustainable business around it. There are several selective examples of massive startup successes that we hear, of founders who worked out of a garage and just built something they wanted only to find that millions of others wanted it too.

But it can’t be forgotten that for every instance of a startup that found massive success seemingly despite a lack of methodical process, there are a thousand others that failed for the same reason.

The startup is a self-inflicted degree in business, and perhaps the most thorough education you can get on the subject. So learn as thoroughly and methodically as you can.

Thanks for reading! If you liked this post, feel free to hit the 💚 button below. It’ll help other readers discover it too.