What is customer development?

Customer development is the process of discovering problems experienced by potential customers and solving them. If this process is implemented correctly, products will create value for customers due to the exhaustive research and testing and go on to be successful.

Brilliant entrepreneurs don't really start out with concrete goals, but they constantly assess how to get their vision into peoples hands and reacting creatively.

It's the age where advanced technology is "easily" accessible to most organizations, only the ones that learn to quickly adapt to change survive. Doesn't matter if it's a startup or a well established enterprise.

Products should not get developed or launched until they're assured to have a customer base ready and waiting. The entrepreneur's role is not to lead customers to the problem. The less leading while hearing your problem getting mentioned, the more validation you get.

The customer development model has 4 parts:

Customer discovery

Customer validation

Customer creation

Company building

The goal is not to simply understand customer behavior, but to change it and build a sustainable business around that change. People usually try to guess what’s good for the user and they’re mostly wrong, no matter how good they are. Entrepreneurs should learn what their customers really need, and use that knowledge to build what they’re willing to pay for.

While it’s very uncomfortable to ask questions that prove your assumptions wrong, it’s essential for success. Regarding what I said earlier, if you’re initial assumptions are proven wrong you have to adapt and change your mind and roadmap. Always remember that you’re not Steve Jobs. Nobody is. And most likely you’re not building computers, but software. You won’t be able to predict customer development and you have no idea what you’re going to learn until you start. The ability to adapt as you uncover new information is priceless.

Most likely your business model is loaded with opinions, assumptions and guesses (along with hope and vision), that’s why you need to get out of the building as validate each of those guesses in the model. I cannot stress this enough.

From your first customer interview, you will learn that the context of the problem you’re trying to solve is much broader than you and your team imagined. Customers make the product successful. If your solution will solve their problem so well, they will become your sales team. If the thought of not being able to use your solution will make them very disappointed (>40%), the you have product-market fit.

Customer development is a way to reduce your business risk by challenging assumptions about who the customers are, what they need, and why/how they buy. The risk of not doing customer development is building something no one wants to buy. Everything in customer development is about testing hypotheses. Think about it this way: if you’re wrong, you want to find out fast, right? If you can’t find customers or they contradict your guesses, you pivot the product or the market (more nicely put - you modify your hypotheses).

Customer development really brings you a deeper picture of your customer and the competition, the opportunity to uncover new ways for differentiation and you’ll definitely reduce the amount of product you need to build.

It’s easy to start. Just take your current assumptions and a customer segment and go have a conversation. It’s not really important if you’re right. Each time you’re wrong, it will help you make better guesses next time. Have narrow hypotheses to focus and progress faster. If the scope is broad, you end up doing a lot of interviews with no actionable data. Demographics aren’t customers.

In the beginning you should look for the most enthusiastic and passionate potential customers. If you don’t find them now, how were you planning on finding them after you built the product?

Steve Blank calls them “early evangelists” - people who are willing to take a risk on your unproven and unfinished product.

I’ll detail each of the steps in future posts, but what you should remember is to start with:

1. Identify a need
2. Think of potential solutions
3. Validate assumptions
4. Deliver an MVP
5. Repeat (constantly reevaluate your solution)

You need to make it clear to your team, stakeholders or cofounders:

1. Who your customers are
2. What problems and pains they have
3. What is their current behavior
4. What are they willing to pay for
5. How to build a solution that works with how your customer buys and uses

And lastly, customer development is not product development. Product development is the process of building a new product or service and bring it to market. Product development equals delivery. Customer development is finding the truth on what to build and for whom.

Contact us: engineering@the-lean-startup.com for customer development

Product manager responsibilities

There are multiple responsibilities to a product manager. I'm going to go through some of them because the ideal product manager is a T shaped individual, with deep knowledge in one field and multiple experiences in other fields. An ideal product manager should have experienced every role in the PDLC (Product development life cycle).

Strategy and vision

A first key responsibility is about strategy. Strategy needs to be clearly articulated to the product team so they understand the intent behind the new product or iteration. The "why" needs to be supported with data and results from the customer development phase.

The strategy must also make mid or long term sense to the business goals of the company.

To be more specific, the product manager needs to make sure stakeholders, the product team, sales and marketing understands what is going to be built, what the customer value is, what pain is it solving and who the product is for.

Roadmap

After the "what" is articulated and support is granted (I always think that the first responsibility is a pitch to secure funding and support. This second responsibility is having a plan that makes sense) and vision is set, it's time to create an execution plan. This will include high level features and experience mapping for the customer journey to solving their pain.

After the high level features have been prioritized, the team tries their best to estimate them so a timeline can be created. This timeline will usually be rejected by stakeholders :). In a truly agile environment the roadmap will change and the team should always be working on the most important customer value it can deliver. In a waterfall environment, specifications change slowly.

Tactical leadership

The product manager is responsible for the groomed backlog, granular features and user stories and making sure the team is not stuck and requirements are clear on what needs to be built. The product manager is the glue between design, engineering and product and he/she has to ensure that there are no gaps and the team is able to deliver on expectations.

It's also important to deliver a minimum viable product (MVP) at first so the product manager can start asking for feedback from initial customers, stakeholders etc.

Launch and iteration releases

After the product has passes quality control, the value proposition has been validated by test customers, the product or feature is launched. This is where the product manager needs to start gathering quantitative feedback and decide what goes in the next iteration. Basically there will be a lot of decisions on what not to build.

If things go at least half of how they're expected to go, the product usually needs to enter a growth phase, reach maturity and a stabilization phase (months to years).

Contact us: engineering@the-lean-startup.com

What is product management?

Product management is the process where a product owner/manager translates customer pains into solution requirements while making sure the solution is profitable to their business. The product manager needs to bring clarity to their team.

So I started arguing that product management is a process. While the product manager has multiple jobs to do (will detail on this later) product management is the process where there is a clear communication path from the validated customer pain to each granular task that goes into the backlog and eventually gets shipped back to the customer. If we live in an alternate universe, things stop here. But usually customers come with feedback and lots of it.

The product management process

The ideal process is when features or product ideas come form a validated market need (there are other cases, but I won't cover them in this post).
A validated market need is when a customer segment has an important problem and "hacked" a solution together to fix it. Hacking a solution can mean using pen and paper for documenting disease progress (non-digital medical journal) or hailing in the street on a rainy day for a taxi - in Uber's case.

In the customer interview process (requires getting out of the building - there are no facts in the building, only opinions), customers should not be asked about solutions or even mentioning your idea to the solution. In this part of the process, product managers should talk 2% and listen 98%. Try to get the potential customer to explain in his or her words the pain and the experience facing doing a particular task. And listen, I cannot stress this enough. Now, repeat this process until you get repetitive answers.

Go back to the team and map that data and create a story map. Tell the customer story and make personas. Feature decisions should be data driven, not opinion given, although sometimes it helps to have an expert on board to confirm certain paths. But usually the customer data is the most valuable resource you have at this point. No usage metrics, churn rates etc. Just raw data that needs to be empathized into a solution.

After you figured out how to clearly state the problem and the customer story the product manager needs to prioritize. What is the most important problem that the potential customer would highly appreciate our product to solve? Does it make sense to the business? Would the customer pay for the solution? How much would the customer pay for it?

The product manager prioritized some problems to solve based on his "feel" from empathizing with the customer, data, their business, the market, the current competitors (competitors can be pen and paper - not every digital product is better than pen and paper because in some markets there is a restrain from adopting a digital solution over an analogue one) etc.

After the prioritization, user stories need to be created. A user story is just a part of the feature that is expressed somehow in non-technical customer language. As an example, these are user story examples:

• as a customer I want to login with Facebook
• as a customer I want to add a reminder
• as a customer I want to have home/work suggestions when starting my navigation system

Let's take the last one as a thought process. I don't believe any customer said 10 years ago that this is what they want to see when their navigation system boots up but a product manager decided that these are the 2 most important locations to navigate in a customer persona. The customer would want to navigate to work and back home. In the interview customers might have said that they use the car to get to work, grocery shopping and taking their kids home from school. This is customer empathy.

Getting back to the user stories. After they were created, they are tackled by the development team, going through CI processes, tested by QA, validated by the product manager and presented to the stakeholders. In each of these steps there is feedback and fixes are in place (again, prioritized). After a significant and also minimal amount of features are build, tested and validated, the team has a working prototype or minimal viable product. 

The product manager takes this product back to some of the initial customers in the interview process and gets it in their hands: What do you think of this solution? Watch the customer interact with your solution, just watch. They're going to have questions, not find things and give feedback. 

Take this feedback back to the team. Rinse and repeat.

This should usually go to the next level when you make your initial customers love you and get to product market fit.

This was a shot presentation of the product management process. There are multiple things that go wrong and products that fail. But you should always remember: talk to your f****** customers! Assumption is the mother of most fuckups. 😵

What is product-market fit?

There are many definitions, but you can basically "feel" product-market fit when the market pulls product out of the startup (as defined by Marc Andreessen in the only thing that matters). Customers are banging on your door to get the product and this is your first API performance/load test - usage is growing as fast as you can add more servers.

Your product does not have to be great. it has to barely work and solve the market problem. The market does not care about how good the team is either, as long as it can produce a satisfactory product.

There is only one way to strive for this holy grail that is called product-market fit. Doing customer development. I always imagine the market as one circle, and the product as another. Finding product-market fit is a process in which you either move the product to overlap the market or vice-versa. You may pivot (change product or market) until you have fit. 

You can always feel when this isn't happening: usage isn't growing, page views are meh, sales cycle takes too long, deals never close and word of mouth isn't spreading. Basically customers, aren't quite getting value out of the product. Imagine the overlapping circles again: it's like your product circle is satisfying 1% of the wanted market circle and the other 99% are users in other markets that you're trying to get on board. They don't really see it because you're not solving their pain. The hard part is to finding more of the 1% types of customers. Again - customer development.

There's something more to say about this holy grail. I think that products that hit this landmark in their iteration also get an advantage from the market - if they satisfy 10 users so well, these users might begin to share their positive experiences with others. All of a sudden, customers become your sales people.

There is also a core metric to test if you're unsure about this achievement. Ask customers a single survey question: "How would you feel if you could no longer use this product?" If >40% respond with "very disappointed" - you need to start scaling. If the percentage is lower, continue doing customer development and iteration until you hit the 40% benchmark.

I think you can also measure the fit of the product when a large percentage of users get to the "aha moment" - it's like meeting an attractive person and realising you're attracted to her/him. There's no misunderstanding or uncertainty about it. Replace the person with a product and the "aha moment" is the moment a user realises the value of a product.

A product manager has to bring clarity to their team

Satya Nadella, the CEO of Microsoft, argues that clarity is a trait he's looking for in new hires. I'm not taking things out of context, because he also said that he looks for energy in new hires, but that's harder to define. You can take a look at this 2-minute video interview:

Returning to the product manager, I think clarity is something vague at this point and needs to be split. Whenever you have a new product manager or owner, he needs to bring four major critical contributions to their team. The product manager needs to have deep knowledge:

1. in the customer segments
2. in the data
3. of your business and its stakeholders
4. of the market and industry

Customer segments

Clarity in the customer segments is not just having complete profiles but having the ability to empathize with these customers. Every decision that goes into the product must bring value to the customer - this is not just a fancy sentence - anything that goes into the sprint from the backlog has to actually be something that solves a known product problem or a new important customer problem. 

Regarding the enforcement to the sprint I made above, keep in mind two inconvenient truths that cause failed product efforts:

1. at least half of our ideas are just not going to work - customers ultimately won't use it (which is why you need customer validation and customer discovery early in the process)
2. it takes several iterations to implement an idea that delivers necessary business value (every agile product ever except car companies with unconnected cars) - you can argue that all cars are basically the same (for now) and any car solves more or less the same customer problem - taking you from A to B (some are self-driving, some have leather seats, some are fast etc).

Data-driven decisions and stakeholder management

I'd make the statement that any product manager that has a successful product or is building one that's going to survive, has to be data-driven. Typical roadmaps nowadays are the root cause of waste and failed efforts in product organizations. The motivation: that it's easy to create processes that govern how you create products and bring innovation. Yes. Some stakeholders think that innovation can be solved with a fixed process. 

This type of organization needs to wean off typical roadmaps and focus on business outcomes, providing stakeholders visibility so that they know your team is working on important items and eventually make high-integrity commitments when critical delivery dates are needed. Part of this is managing stakeholder expectations and engaging them early in the product discovery process with (ideally) high-fidelity prototypes. To manage stakeholder expectations, a product manager needs to bring clarity to the table and also understand the stakeholder's context.

Being data-driven also means that you, the product manager, gets to decide what is built. If you get backlash, bringing customer data to the table, needs to be the only source of truth. But be careful, the decisions, have to be compliant with the long term vision of the product and also make business sense.

Market and industry knowledge

The product manager needs to be aware of the organization concerns and also about the market conditions. She should have knowledge of valuable business models and consciously apply a specific model when required. 

Your team needs to be aware that the product meets the needs of a specific market. Market knowledge also means being aware of the competition and that is the differentiator to your product. Depending on your customer segments, the product manager can also assume the size of the market based on customer interviews and quantitative numbers extracted from that data. When trying to figure out the market size and condition, the product manager also needs to be in sync with marketing, sales, customer success, finance, legal, BD, security etc, before making market statements. 

Again, talking with different people inside the business and ecosystem can get the product manager closer to the market truth, limits and movement.

Product managers need to bring clarity

While the entire team is responsible for product success, only the product manager is responsible for product failure. The argumentation here is very simple: the product manager had all the tools, people, team, data and access to key people. If the product is a failure, the decisions were wrong and the product manager made them. The product did not solve an important problem for the customers in the market he researched.

Possible reasons for bad decisions: 

• untested assumptions
• no real empathy for the customer
• company constraints
• confirmation bias
• wrong direction
• wrong timing
• the wrong market
• the wrong problem solved
• low-quality product
• failure to satisfy early adopters
• failure to listen to customers
• scaling too early

Make 10 customers love your product. If you manage that, you'll be successful. 

What is customer discovery? (short version)

This is the first step in the customer development life-cycle.

You need to find who the customers for your product are and whether the problem you believe you are solving is really important to them. Leaving guesswork behind, you should get out of the building to learn what the high-value customer pains are, how your product solves these pains and who specifically is your customer - has the power to make or influence the buying decision - and user - who actually will end up using the product on a repeated basis.

Keep in mind, that this step is not about collecting feature lists from prospective customers, and neither tunning a lot of focus groups. If you're a startup, the founders define the first product. The job of the customer discovery team is to see whether there are customers and a market for that vision.

In this particular step of the process, you should be in the field, listening and discovering how your customers work and what their key problems are.

As action points: you need to dig for negative feedback.

The goal of customer discovery is to turn the founders' initial hypothesis about their market and customers into facts.

What you should know before your team starts building a new product

There are some questions you and your team should answer before starting out to build a product:

1. Is there a group of customers who would buy this product?
2. Is this a significant pain point for them, or a minor one?
3. Are people really excited about an idea like this or is the response pretty meh?
4. How big is this group of customers potentially?
5. Is there a change or a tweak or a full scale revision to this idea that would radically increase the number of customers?
6. What price might customers be willing to pay?
7. What solutions are customers currently using to solve this problem? Is this solution pretty good or pretty bad? How receptive are people to the idea of a better solution?
8. How much are people currently paying for this alternative solution?
9. How would you reach these customers? Is there a place where they get together? One or more websites they all read? Conventions they all attend?
10. Would these people tell their friends about your idea, or not? (this is a measure of word-of-mouth resonance)

These are 10 basic questions that need a lot of effort to be answered. But the effort needed is way smaller than the pain of building a solution for a problem nobody has.

First thing to do is get out of the building. There are no facts in the building.