Starting Products: The Early Days or Lots of Free Time With Too Many Ideas
This is the second post in my Starting Products series. You can read the first post here.
Being the first PM at an early stage startup is a really weird experience because it’s not always clear what you should be doing. There’s no product, much less customers, so the typical “look at metrics/goals/customer notes” you’ve done before on day 1 at bigger companies doesn’t work. You are often hired at this weird moment where engineering is starting to build something, but it’s going slowly so there are a lot of meetings where the team sits around pontificating about what they will one day build. Frankly it’s often unproductive time as it’s all opinion vs opinion with no regard to customer need or feasibility.
As a PM, what can you do to make this early time useful? There are 4 key things you should do during the early days: learn, research, write, and experiment. Let’s dive into them.
The first thing you should do is learn, both about the company and about the domain.
In terms of the company, what you want to learn is who does/knows what, what are the existing processes (if any), what decisions have been made so far and why, and what work and exploration has occurred. There’s a good chance there are early prototypes the team’s moved on from — ask to see them and what worked/didn’t work with each.
Use your new person status to ask a lot of questions, and if something doesn’t pass the sniff test, push on it a bit to understand why it is how it is and use your fresh perspective: you never know what comment you’ll have or insight from your previous experience that helps the team out. My first week at Pixar as an intern, someone was explaining a video encoding process to me where files had to go back and forth from a Linux box to a Windows box to use a specific codec. I asked “to simplify that, did you try using WINE (a tool that let you run some Windows applications on Linux)?” They hadn’t thought of it, and it turned out it worked and simplified the process. I did also ask a lot of much less insightful questions while learning, too :)
There’s a good chance you’re new to whatever specific domain the startup is working in. Good PMs will use this early time to learn as much as possible about the domain, from “what are unique needs our customers have” to “what is the unique technology we’re building, how does it work, what are the pros/cons/limits/etc.” to “who are the competitors in the space.” If you don’t find answers to some of those key questions — especially around customer behavior — note it and work on finding the answer during the research phase.
Founders, a critical trait to look for in startup PMs is if this person likes to learn and can understand what they’ve learned. Try asking them in an interview to tell you something interesting they learned lately.
Your company will be focused on solving a specific problem. The early days is when you will do customer development to identify your initial customers, learn what they’re currently doing to address this problem, what they’re paying to solve it, and any other relevant information you can learn about what the product needs to do to fit into a customer’s life successfully.
There are books written about how to do customer development well — I recommend Lean Customer Development by Cindy Alvarez — so we’re not going to dive into full tactics here, but I want to share some tidbits I’ve found early-stage startups have to be especially conscious of around “ideal self” vs. “real self” and how it relates to identifying your customers and asking pricing questions.
People want to please each other when being interviewed or surveyed and very few of us are self-aware enough to differentiate what we say we want vs what we truly want, leading to false reads about our customers. This is called “ideal self” vs. “real self.”
For example, if I ask if you want to be healthier, most people will say yes. If I’m making a health product, this sounds great — I have a lot of customers! But this is a false read and many people won’t actually buy my product because that wish is an ideal wish and they won’t actually take action to achieve that goal. Instead, if I ask what people have done in the past 6 months to get healthier — have they worked out, had more fiber to eat, or skipped baked goods as a snack — I’ll get a much smaller subset that’s actually taken action. But those people are much more likely to buy my product and have useful feedback because they really want to be healthier.
Focus on understanding what customers are doing now to solve the pain point you’re addressing. This lets you find who your customers really are as those are the people who will have valid feedback. Also note if you’re finding enough people with this pain point to justify the development expense. If the people you’re talking with haven’t found some way — even if very convoluted — to address whatever pain point you’re trying to solve, they’re not your customers.
In early research, inevitably you will do pricing research to get a sense of what price point you’ll want to target, which will drive many decisions. Pricing is a whole discussion unto itself that I’m not going into here, but I want to share ways I’ve found to get more useful data from early pricing research.
People are really bad at answering pricing questions both because of the ideal self issue and because they often don’t have good mental reference for what the product you’re building should cost. You’ll get much more reliable data focusing on how much money customers currently spend to solve a problem or what similar-ish things they’ve spent money on.
For example, companies that make kids’ toys talk about the “supermom effect.” When they’re building educational products, they will do customer research. Parents love products to help their kids grow and learn. When the company tells parents that this potential product will be $299, 95% of parents say they’ll spend anything to help their kids and will buy it. It seems like this is a marketer’s dream and a no-brainer to build, even at $399. But consistently these companies find that if they build this product, no one buys it because it’s too expensive. That’s the “supermom effect:” parents ideally want to be superheroes and say they’ll do anything for their kids, but the practicalities of real life limit “anything.”
Instead, these companies have learned to focus on how much parents spend now on products for their kids. If you ask “what’s the last $299 product you bought for your child,” you’ll get answers like “we never buy things that pricey for our children.” If you ask “what’s the average price of a product you buy for your kids,” you might hear $50, which is 1/6 of the initial target price, telling you your product will be perceived as expensive and a hard sell. Asking what people actually spend shows the real behavior, eliminating the “supermom effect.”
Focusing on what customers actually spend matters for all domains. I worked with a company making a smart toy for dogs and cats. It’s actually quite a brilliant product and the founders were very smart. The people who bought the product loved it. But it sold for about $299, and since most people were used to $10 pet toys, most people would prefer to buy 30 x $10 toys for their pet instead, so if a pet didn’t like a toy, they were only out $10. The company’s had trouble growing because even with how much people spend on their pets overall and even though pet owners say they will do anything for their pets, asking them to spend 30x what they normally do for a single toy isn’t something they’ll really do.
Pricing questions are even harder when you’re making a new category product — one where there’s nothing comparable — because people don’t have a valid reference point to understand the product.
One founder I know who was building a very science-fiction-like new category product would randomly talk to people in cabs, at bars, etc.. He’d tell them what he was building, he’d ask what they think it’d cost, and they’d think it sounded amazing and tell him they’d pay tens of thousands of dollars for it. Afterwards, he’d come back and want to raise the price because a random person in a bar said they’d pay more. The marketing team cringed each time he’d do that, asking themselves, “what are we going to do, because we can’t sell it at that price — it’s out of range of what people actually spend.” When’s the last time you paid tens of thousands of dollars for a consumer product?
Ultimately, pricing is a complex subject with many factors finally determined much closer to when you actually ship, but if you spend some of your early research time looking at the “real self:” what people pay now to solve the problem, you’ll go into those pricing discussions much more informed.
I’ve consistently found in the early days, there are lots of meetings where people insist the product has to do X. And there are lots of meetings where stakeholders show they have different ideas about the product vision. How do you capture everything to make people heard and also create a unified vision? Product requirement documents (PRDs) are a great place to do so. PRDs are controversial because waterfall-style ones would take forever to write and then be out of date, making them useless. Let me share why I’ve found them valuable, how to write one well, how to keep them useful, and how I’ve seen different companies use them.
PRDs are valuable because they provide alignment, help people feel heard, and clarify the project scope leading to prioritization.
Unlike environments where you’re iterating on a shipped product, in early stage startups, there’s a lot of work to do to make the product, and people have different visions of what it will look like because so little exists early on. Taking time to write a comprehensive PRD first provides alignment — here’s the product vision written down in a place you can point to and discuss, and you will work with stakeholders to make sure you’re aligned. After you’re aligned, by having an agreed-upon vision written down, it’s easy to share it with new team members to get them aligned.
A PRD will help people feel heard because all the things stakeholders talk about — good and wishful-thinking — are captured as requirements. It’s also the place to capture all the table-stakes things that need to happen but people don’t discuss in meetings, like login systems.
By capturing a comprehensive list of requirements, a PRD makes the full scope of what you’re building clear. This list of requirements will be even bigger than you might imagine because unlike in established companies with infrastructure, startups have a lot of table-stakes stuff that aren’t hard but take time to build. Login systems, analytics systems, update mechanisms…it all takes time to build. Inevitably, stakeholders will see the product requirements are big and will be willing to work to assess what are the key things you must do in v1 and what’s the stuff that you could do later, helping to reduce the time you spend talking about the crazy stuff that just won’t happen in v1. (This is where the “lots of free time with too many ideas” problem gets solved.)
Well-written PRDs have two parts: the first is more prosaic and defines the background, the problem, why you’re the solution, who’s the customer, and your north star metrics to measure success. The second is a mix of a narrative describing the product/customer experience and then a table of requirements breaking down what needs to happen to deliver that experience.
In the table, using the “as a <persona>, I want <req> so that <reason>” format helps prevent requirements from being prescriptive and makes the need clear. I also have columns for an example and rationale to make sure the requirements are very clear. Of course there’s a priority column, too.
The requirements tables is also where you’ll write out target specs for performance. How fast should something happen? What lighting level does something need to work in? How much audio bleed can a device have and still be acceptable? That specificity is valuable because it informs engineering’s early choices, especially if you’re working with hardware where component choice drives capability. Make sure you treat these specs as a starting point for discussion and not the final word, though, because sometimes the ideal spec won’t be achievable or will have tradeoffs to achieve.
To make sure the PRD remains useful, as you learn more throughout the development cycle, update the PRD (and communicate your updates) to ensure that it remains the one true source of what you’re building and how it will fit into customers’ lives.
Once you have a PRD, companies use them in different ways. One company I was at was very excited about PRDs and wanted them for every project. But despite using scrum for development, they treated PRDs more like waterfall documents. Any changes required a full approval process and multiple sign-offs. The PRDs helped with early alignment and planning, but the lack of agility made them less useful as the project evolved, leading to engineering — not product — making product decisions in the spur of the moment, often prioritizing what was easier for them rather than what was good for customers.
At a different place, the founder hated reading long documents and disliked the idea of a comprehensive PRD. I wrote one anyway. A number of people told me they found the PRD to be a great reference, seeing the decisions we’d made and key specifications in one place. Consistently, I the founder would ask for information I had in the PRD, just in a different format, so I was always copy/pasting a subset of info from it to provide him the information he wanted in the format he wanted, quickly reacting to his asks.
During the early days of the company, when you’re building something new and unique, there are likely a number of risk factors, which you’re placing a bet will work out to build the product you intend. These risks range from technical risk to value risk. Use the early days of the company and project to de-risk these elements!
To de-risk the technical issues, work with engineering to prototype key parts of the system. Define the high-level goals for the prototype, and build it as fast as possible. It’s OK if the prototype is only focused on one very specific problem because focusing will let you work faster. Generally, the first time you build something, you build it wrong because you don’t know what the unknowns will be, and getting something up and running lets you learn. As you solve these specific questions, you’ll inspire confidence in the project and build the team’s morale.
At Lytro, I was originally hired to build the mobile app to make it possible to share photos right from the camera, and on my first day, I had 3 people tell me that would be impossible due to major technical challenges. My team thought we had ideas for how to solve those challenges in a way that would easily fit into a customer’s workflow. The first thing we did was prototype the riskiest part of that workflow. The prototype was rough and fragile, but it gave management the confidence to move forward with the project, and we made the impossible possible.
Additionally, especially in hardware companies where your time to market is long and you need to raise more money, early prototypes become part of investor pitches. As a PM, you should work with the stakeholders to set the higher-level experiential goals for these prototypes. These prototypes will be rough and likely barely work but what are the overall key parts of the experience that must work? Are there little features you can help define that provide a lot of bang towards the overall goal with minimal effort?
Finally, sometimes you can show your prototypes to customers to see if they find your solution valuable (see the first post in this series for a discussion about showing customers your work). Showing customers these prototypes also lets you gauge how much of a pain point this problem is for customers. If customers want to keep your prototype — even with all the flaws — you’re on track to build something they want because the value it gives outweighs any pain from the unfinished prototype. If customers don’t react, assuming the prototype works technically, you should look more carefully at the potential value you’re providing because this is an early sign that customers don’t need or value your solution.
Once you’re at this point where you’re experimenting, learning, and iterating, you’re on your way to building a product! And having now done customer research and put together a unifying PRD, you will have helped focus the company’s future efforts and made good use of your time.
Continue reading part three: When You Have to Guess…