From space to idea in 1 month

It’s exciting to help a company expand into a new customer segment or line of business, but it’s also daunting - where do you begin? Expanding on my earlier writings, this post offers a roadmap for going from a vague direction to a compelling, high-confidence product strategy in the space of a month.

On the way to building a hugely successful company, most startups will need to expand from their initial product-market fit into new geographies, customer types, or product lines. Typically, executives tap a senior person in product, strategy, or business development to explore these new spaces; if a company is doing this for the first time, however, the leadership may not provide much direction on how to structure this exploration, and as a result teams often waste a lot of time or produce lackluster results.

This post outlines the structure that I use to identify and validate opportunities. I’ve found that the fastest a team can reasonably produce a compelling, high-confidence product strategy within an existing company is about a month. If the team gets unlucky and some of the initial directions end up being dead-ends, it can take up to 8 or even 12 weeks. For those familiar with Design Sprints, this process is essentially a design sprint elongated over the course of a month in order to handle the increased ambiguity.

Setup: team structure

The ideal team for this sort of work is two people – a generalist “maker” and a generalist “business person” – who are full-time on the effort and have existing rapport. It’s helpful to have one person who can make things (prototypes, designs, etc.) so the team can produce and rapidly iterate on product concepts to show to customers, and it’s helpful to have one person who loves talking to customers and is well-versed in business fundamentals & customer needs.

A partnership of two, full-time people is ideal - with three people or part-time teammates it’s harder to stay fully in-sync and you end up slowing down due to the overhead of scheduling and context switching; on the other side, a team of one can end up getting stalled or going down a dead-end without a teammate who can offer a different perspective and challenge ideas. While the team should stay focused on executing, I do recommend doing this work “in the open” and making work products accessible to stakeholders as the outputs take shape.

Week 1: internal interviews and existing research

By the time the company decides to send a team to explore a space, there is usually a wealth of hunches, opinions, and insights within the company about potential new directions. This is a great place to start, as it provides a useful primer on the space and insights into the goals of key stakeholders.

By interviewing 5-10 key people at the company and doing a day or two of external research (trade magazines, videos, competitor sites, expert interviews, academic papers, etc.), the team can usually get a good sense of what the company thinks are the major customer problems to be solved and how they fit into the space as a whole. Executives are good people to interview (especially the ones sponsoring the project!), but also talk with tenured customer-facing employees who have deep context on the space. Based on these interviews, the team can identify which customers they want to talk to first, write up a user research script, and schedule 10-15 hours of customer interviews for the following week.

Week 2: Customer interviews

The second week is all about spending as much time as possible with customers - ideally, 10-15 hours of face-to-face customer time. The whole team (two people, if you took the advice above) should be on all the interviews to maximize shared context, with one person leading the interview and the other as note-taker. Early in the week, lean on the script that you created from the internal company understanding, but as you learn more from customers adjust the questions you ask and the language you use to dig in on the pain points that seem to be the most acute.

The goal here is to find a set of problem areas that:

1. Seem fairly common in at least one identifiable subset of customers,
2. Where you can describe the problem in a way that the customer would say “definitely, you said it better than I could say myself,” and
3. If you offer to solve the problem for them, the customer would say “oh yes thank you that would be amazing.”

Remember to focus on the customer needs at this stage rather than the business need (customer needs first, business needs second). At the end of the week with the context fresh in your mind, write up customer problem statements or jobs-to-be-done for the two to four needs that you believe are the most pressing - you’ll test these in week 3.

Week 3: Testing desirability of ideal solutions

The third week is about making things, showing them to potential customers, and testing if you’re in the ballpark of a genuine hair-on-fire problem. For each of the customer problem statements, sketch the most perfect solution you can imagine that you could plausibly make and sell. This is not the time to be parsimonious with features - if you think a capability would be compelling, put it in. For each of these “ideal solutions,” create a prototype that looks real and high-fidelity, then go sell it. If people seem to be genuinely jump-over-the-table excited, you’re onto something; if not, either tweak the solution you’re pitching or schedule more interviews to refine your understanding of customer problems.

It is important that the prototypes you create appear to be actual products so that you can confront the customer with a real choice - do they want to buy the product today, or not? I expanded up on this in an earlier post about testing desirability, but it’s critical to present the customer with something that seems real. My favorite tools for this are 1-pagers and 90-second screencasts of potential products, but spoof landing pages also work well. If you do cold-outreach with your prototype to 20-50 people you think would be highly interested customers and over 25% respond with interest, you’ve got an idea worth exploring.

The reason for loading the prototype with potentially-compelling features is to maximize your luck surface area: you’re not validating the solution, you’re validating the problem – and a good way to do that is to see if customers enthusiastically reach for a solution that is close enough. If you get lucky and see this sort of enthusiastic response to your prototype, week four’s design sprint will help you refine the idea into the specific something you should build.

Week 4: Refining the idea with a Design Sprint

The goal of the fourth week is to hone in on the approach that will serve as your MVP, and to start getting others involved. By this point, you should have a customer problem that you’re confident is real and important and some early signal about potential solutions. This is the ideal set-up for running a week-long Design Sprint to further refine your understanding of the problem and narrow in on the specific features that will be the backbone of your first version.

Running a Sprint at this stage will also create shared context with the rest of the team that will go on to build the MVP. With luck, by the end of week four you should have a crisp understanding of the problem you’re solving and the sketch of a promising initial solution for the team to build.

Epilogue: confirm feasibility and business viability, present to execs

After four intense weeks, it’s natural to want to either take a vacation or just go and start building, but there’s one last critical step: making the business case to executives. While it’s essential that your approach solves a real problem for customers, you also need to make sure that it solves a business need as well. This is where you should estimate the total addressable market, model channels for customer acquisition and associated costs, and identify any legal or regulatory concerns that need to be addressed early on. At this early stage, many of these will be educated guesses, but it’s important to show that initiative could be wildly profitable along with the critical assumptions left to validate.

With these inputs and the learnings from customer interviews, desirability testing, and the design sprint, the team can create a document that outlines the vision, strategy, customer need, and business rationale for the chosen direction. The team can then present this case to executives, get their feedback and suggestions, and ideally end the month with the approval and investment to go build an MVP.

Using this structure, a small team can go from a promising space to a high-confidence, validated strategy with executive sign-off in a month. If the team isn’t full time, there are issues scheduling internal meetings or external interviews, or the team hits some dead-ends along the way it can take a bit longer, but following this structure the team can still make steady progress. Armed with a deep understanding of the customer, an initial promising strategy, and executive buy-in, the team then can charge ahead to get a product in the hands of customers as early as possible, and iterate, iterate, iterate until achieving initial traction and product-market fit.

A big thank to Philip Jones and Megan Scheminske for their help and feedback in improving this post.