[Day 3] Designing the Product Using a Method from the Lean Startup

[Day 3] Designing the Product Using a Method from the Lean Startup

Note: This is Day 3 of a 10 Day series on building a new online startup from idea to launch. You can find the previous posts here:
[Day 0] Let’s Build an Online Startup in 10 Days
[Day 1] Creating a Value Proposition for Our Idea
[Day 2] Refining the Business Model and Naming the Baby

To summarize: We are going to build an online product called N-ter that lets users track and manage their job applications in a single place.

Today it’s all about figuring out how we can test whether our idea is viable and detailing how our online product is supposed to work. We’re covering:

  • Breaking down the business idea all the way to a product design for our MVP.
  • Utilizing a lightweight version of the build-measure-learn feedback loop, a core concept from the lean startup methodology.
  • Designing….. a carrot. Yeah, that’s right – that orange edible thing. Read on to figure out what that’s all about.
  • Creating concepts for our website.

 


Business Plans Never Survive First Contact with Reality

My goal from the very beginning of this 10 days series was to show you a way of how a simple online product can be built quickly and cheaply, even as a non-coder, as long as you’re willing to acquire some basic skills. The way I’m choosing and describing is one of an infinite number of ways how this can be achieved. In what I’m showing you today, we are utilizing tools from two very popular methods: The Lean Startup and the Agile Development methodologies. I think it’s important to mention that what you’re seeing from these methods in this post is just touching the surface of what they are about. I’m picking a few specific tools from the respective methods that fit very well into the 10-day approach I’m applying. It’s a way that’s worked for me and can also work for you.

So why are we employing some of these methods? Because in this series our main focus is to learn from the real world as quickly as possible, without spending weeks of our time on coming up with plans that don’t hold up anymore once they come in contact with real users. And building viable (or “shippable”) products as quickly as possible is rooted in the core of both Lean Startup and Agile Development.

That being said, let’s get started!

We are picking a core concept from the lean startup methodology: The build-measure-learn feedback loop. In a lightweight application of this method we are going to utilize one specific tool on our way to designing the Minimum Viable Product.

 

The Build – Measure – Learn Feedback Loop

The concept of the loop is easily explained. It basically argues that the path to validate the assumptions about your customers consists of three parts: Building the actual product, Measuring the results this product produces and Learning from these results. Once you’ve learned from the first iteration, you apply your lessons learned and build the next version of the product based on them. The key goal is to minimize the time it takes you to get through one iteration of the loop, so new learnings are applied as quickly as possible to your product, which is constantly improved based on real user behaviour.

Every of the three phases generates output that is used for the next phase respectively, so this is how the entire cycle looks like:

Build -> code -> Measure -> data -> Learn -> ideas -> Build -> code -> Measure -> … and so on.

Now, while this loop describes the overall process, there is one adjustment you need to make when planning your product design. The entire purpose of this method is actually to Learn, not to Build. Building is “just” a necessity to achieve learning from the real world. That means, when planning this process, you need to think backwards. Here’s how it goes:

  1. Figure out what you are trying to Learn
  2. Define how you are going to Measure the thing you want to learn
  3. Figure out what you need to Build in order to get the data that enables you to measure

 

There are numerous tools and tactics for every of the three phases that you can use. Here is an overview of the tools for every stage:

The Lean Startup – Build Measure Learn from: http://theleanstartup.com/images/methodology_innovation.jpg

For every of the three stages, we are going to apply one specific method (that’s why I’m calling our execution “lightweight”).

  • Learn: Falsifiable Hypothesis
  • Measure: Conversion Funnel / Funnel Analysis
  • Build: Minimum Viable Product (MVP)

 

Step 1: What Are We Trying to LEARN?

The key to learning is to validate assumptions that you create about your user’s behaviour. You can technically come up with an infinite number of assumptions, but try to keep it short and focus on the obvious ones when starting off with this method. While there are many assumptions you can make, there is one special form of them: The ones that make or break your business idea are called leap of faith assumptions. These are the key assumptions that need to be validated in order for your business idea to work. If a leap of faith assumption is not validated, you know it’s time to Pivot. A Pivot is an adjustment in your idea or business model, that enables you to steer in a new direction and come up with new assumptions to validate.

So, to keep it simple, we’ll come up with one single assumption about our idea – the key leap of faith assumption:

>> Job seekers find value in tracking job applications in an online tool.

So how the heck do we test or verify this?

The assumption above is not really testable – mainly because it includes a “nebulous” term: value. What exactly is value? What is value for the customer? How do we measure value?

Now, to get some actual validated learning we need to break down this assumption and come up with something that is called a falsifiable hypothesis. The key word here is “falsifiable”. Can we falsify “value”? No – there are always ways to discuss around this word and put it in a different light. Can we falsify “Two people visiting our website today.”? Yes – either they did or they didn’t. Easy.

The falsifiable hypothesis I came up with for our idea:

>> I believe that 1% of the users visiting our website will sign up, create 3 job applications and return to the website twice within the first two weeks.

This is something that we can actually validate with our MVP. Why did I choose exactly those figures? Mainly this is an attempt to separate the users that find the tool valuable from the ones that do not.

1% of the users: This is to test whether the idea is scalable. You can always accidentally find that one-in-a-million person that thinks a bucket of dirt is the greatest thing ever. That doesn’t say anything about our product though. But if at least one out of a hundred users uses the tool frequently, there’s a promise that the idea is scalable.

Create 3 job applications: I assume there will be people signing up, testing the tool and creating 1 or two applications in the process. That doesn’t mean that they are actually using it. So I set this bar with the intention to filter the “testers” out.

Return twice within two weeks: What we need for the idea to work are returning users. Someone might think that the tool is a cool idea and actually create job applications and fill in the data, only to forget about us later and never return. (I myself am guilty of behaving like this sometimes when I discover a new service.) The bar I’m setting is: If a user is visiting us three times in two weeks, he is a returning user.

The combined points above are my definition of a user who finds the tool valuable. Now we can go ahead and figure out how to measure this and what to build to test this hypothesis.

 

Step 2: What Do We MEASURE?

Based on our falsifiable hypothesis, what exactly do we need to measure about our user base? It’s the following metrics:

  • Number of people visiting the site
  • Number of people who have created at least 3 applications
  • Out of those people, the number of people who return to the site twice in 2 weeks

 

These three will enable us to measure the percentage of returning users according to our criteria outlined above. As we also need users to click our affiliate links, so we earn some money (as discussed yesterday), I’m going to add one more metric:

  • Number of returning users, who click on affiliate links.

 

How are we going to measure this? These metrics fit wonderfully to a tool called Conversion Funnel.

The conversion funnel breaks down the exact percentages of users along every step of the conversion from a website visitor to a paying customer. To simplify this, I’m going to say that a paying customer in our case is someone who clicked an affiliate link at least once. I’m well aware that also a non-returning customer could do this, but I don’t see this as a problem.

There are many different ways to design the stages of a conversion funnel – I’m going with this structure:

  • Website visitors (100%)
  • Out of those > Signed up (30%)
  • Out of those > Logged in (20%)
  • Out of those > Created a job application (10%)
  • Out of those > Returning users (5%)
  • Out of those > Clicked an affiliate link (“Paying customer”) (1%)

(I made up the percentages behind the stages to demonstrate the concept.)

By measuring the data along every step of the funnel we can determine in which steps of the conversion process the most users drop out. This is also valuable information to figure out which parts of the product need improvement later on.

 

Step 3: What do we BUILD?

For the build phase, we are going to employ the popular concept of Minimum Viable Product (short MVP). I’ll let a picture explain, as it is much more powerful than words:

How to build an MVP from: https://www.quora.com/How-minimal-should-a-MVP-minimal-viable-product-be

 

Think of the five product stages above as 5 full cycles of the build-measure-learn feedback loop. The result of every cycle is an MVP, so we can quickly test and fulfil assumptions about the wishes of our users.

The hardest thing about designing an MVP is hitting the sweet spot between “minimum” and “viable”. There are many, many discussions and opinions about where that sweet spot is and how to find it (reminds me of another discussion that’s quite similar. 😊)

On a conceptual level, I like to think about the problem using a method from mathematics: the least common multiple.

For the sake of the argument let’s say that all viable products for our problem are common multiples of 3 and 4.

Now, would “1” be a good MVP? No – it’s minimum, but not a common multiple, and therefore not viable.

Would “24” be a good MVP? No – it’s viable, but not minimum.

The actual MVP we are looking for is “12”. It’s the least common multiple of 3 and 4 and therefore minimum AND viable.

The “What is a good MVP” discussion is not nearly anywhere as black and white as our common multiple example, but at least for myself a good framework to think about it.

 

The Carrot/Vegetable Problem

To be able to test our leap of faith assumption quickly, I’m consciously taking the risk that I could be wrong with design decisions and therewith negatively influence our results. In normal words: At this stage, we’re not going to try and validate how exactly the first MVP we are building should look like. From here, I’m solely relying on my own intuition and opinions. Doing that is risky. Why?

Because I could (falsely) decide that a carrot is the best way to give the user what he wants. This could result in the following statement: “Our users don’t like the carrot we gave them, that means they don’t like vegetables.”

A user who visits our website and doesn’t return, might:

  1. Not be interested in tracking his job applications online (“the vegetable”)
  2. Just don’t like the design or functionalities of the tool (“the carrot”)

 

By not validating our design decisions, we won’t know which one of the two it actually was. What we are going to do here is give our users a carrot to figure out whether they like vegetables, but (at least after the first iteration) we won’t know whether they don’t like carrots or vegetables.

For the sake of speed, I am accepting this risk, taking the leap of faith (pun intended) and moving the carrot/vegetable validation to the next cycles of the build-measure-learn feedback loop. If at the next stage we figure out our users like tomatoes better, we’re going to give them tomatoes. For now, let’s just hope that some people like carrots for the sake of our MVP.

 

Designing the Carrot – Our Minimum Viable Product

Before selecting features for our MVP, let’s think about all the use cases we could enable in the tool for our users.

What should a user be able to do?

  • Recording job applications with the following information: job title, employer, date of application, application status, notes, priority, application deadline, file attachments
  • Changing the status of a job application
  • Getting automatically asked about the status of a job application that has not been edited for a while
  • Editing employer data (contact person, phone, address)
  • Sorting job applications
  • Viewing an application dashboard
  • Getting reminded of application deadlines via e-mail
  • Tracking personal job preferences
  • Getting relevant job advertisements

 

Based on the use cases I designed this use case diagram, detailing the web pages we need and the actions the user can take on them.

Use Case Diagram

I assume most of you won’t be able to read the stuff I wrote there so here are the pages we will need:

  • A landing page
  • A sign-up page
  • A login page or functionality
  • A user management page
  • An application overview page (the “dashboard”)
  • A detailed application editing page

 

Now off to the next step, the functionality:

 

Designing Functionality with User Stories

User Stories are one of the key elements of Agile Software Development and its’ methodologies (Scrum probably being the most famous one). I like user stories because they clearly detail functionality from the user’s perspective.

Again, there is much, much more that belongs to executing proper agile development or a methodology like scrum. But these methodologies are mainly designed to enable speedy, incremental product development and to solve collaboration or communication problems in teams. As we are a one-man-development-show here, I’m borrowing one specific element of agile development. The more people you have involved in a project like this, the stronger you should consider properly executing agile.

Every user story consists of exactly three parts and follows exactly this structure:

As a [Who?], I want to [What?], so [Why?].

So you see that every functionality includes information about

  • Who it is for
  • What it should do
  • Why it needs to be there

 

Especially that last information is very important and should NEVER be left out, as it makes you critically think about whether that functionality is really required.

User stories can be used for any kind of design, not only software. Here’s an example of how it can look like:

As a television viewer, I want to switch channels, so I can watch another program.

When designing a product or software, detail the entire functionality of that product in user stories.

I created the user stories for our product based on the use cases I detailed in the previous part. I use Trello to record and manage them, as the tool gives me the opportunity to record more information for every story and move the stories between buckets easily. Here are the screenshots, in case you are interested in the exact stories I wrote.

User Stories Part 1
User Stories Part 2

 

 

When coming up with user stories you can follow this process:

  1. Write user stories that cover every single functionality your users should be able to perform on the system. Don’t forget to include system user stories (As system, I want to…) for automated tasks that don’t have directly to do with your users.
  2. Prioritize the stories according to their importance for the MVP. You can categorize them in “must have”, “should have” and “nice to have” if that helps you prioritize better.
  3. From your prioritized list (the “Product Backlog” in my screenshots), select the user stories that you intend to implement for your first MVP. Make sure you include all stories that make this MVP VIABLE for the user. I put the stories in a separate “MVP” bucket in Trello, so I have a good overview.
  4. [BONUS STEP]: If you want to make testing easier at a later stage, you can include so-called “Acceptance Criteria” in every user story. These are specific criteria, that describe which describe how the product should behave, if the user story is implemented successfully. Defining that right now will make testing your product easier once it’s done, as you just have to review the acceptance criteria for every story and make sure they’re fulfilled. You can read more about acceptance criteria here.

 

Drafting the Website

Based on the concepts above, I drafted so called “mock ups” for the landing page, dashboard and detailed application editing page:

 

Landing Page
Application Dashboard and Detailed Application Editing Pages

Day 3 Summary

If you are following along with an idea of your own, today do the following things:

  • Figure out what the leap of faith assumption for your business idea is.
  • Based on the leap of faith assumption, define a falsifiable hypothesis. Make sure that hypothesis is testable. (Can you definitely validate the hypothesis based on clear criteria?)
  • Based on your hypothesis, figure out what you need to measure to validate it.
  • Based on the hypothesis you’re trying to validate and the metrics you want to measure, come up with a concept for your MVP
  • Write use cases for the MVP. What should your user be able to do from a “business perspective”?
  • Follow the process outlined in the user stories part to create the user stories for your product. For bonus points, add acceptance criteria to your stories.
  • Create paper mock ups for how your website should look like approximately.

 

That’s it for Day 3! Tomorrow, we’ll dive into the following topics:

  • Discussing the services and technology we are going to be using to build the product and how much that costs
  • Buying the domain, setting up the hosting and installing WordPress
  • Setting up website analytics and a coming soon page

 

Meanwhile, sign up for the email-newsletter and I’ll let you know when the new posts go online!

5 Replies to “[Day 3] Designing the Product Using a Method from the Lean Startup”

  1. Hi Alex, congrats to start this experiment. 🙂 Since some weeks, this is also my daily topic and I know how difficult it is to ‘just start’. So, great job Alex… it’s empowering. 🙂

    All the best for you and N-ter,
    Oliver

    PS: I like the tonality and practical style of your posts.

Leave a Reply

Your email address will not be published. Required fields are marked *