Zero to One in Product Management

The PM starter kit for startups & teams

Somewhere between 12 and 30 people, a startup will need its first product manager. Most of the great writing out there focuses on product management in companies of hundreds or thousands of employees. But how does a startup take the first step?

After several years of being “first PM” for various companies, products, and teams, and advising other teams contemplating the shift, I’ve found a few recurring symptoms of this stage. Early on, your scrappy team meets over coffee, decides to build a thing, and then builds the thing. But now, you have 4 people building the thing together, and a salesperson who starts selling the thing. Halfway through development, engineers point out gaps in the designs, and you scramble to fill in the holes. After it’s shipped, you realize it’s missing a key data field so your biggest customer can’t actually use it. And because everyone’s passionate about the mission but laser-focused on their role, they propose a half-dozen new projects that are exciting individually, but don’t add up to a coherent whole.

First, let’s shift the narrative from job titles to job contributions. Product leadership can also be done by a founder or engineering lead with the right attributes: technical enough to earn the respect of engineering teams; sharply insightful about competition, markets, and software economics; and with deep reservoirs of empathy that let them walk a parsec in their end customers’ gravity boots. (Thanks, Rich Mironov.)

There are 3 key product practices (not documents!) that are almost always helpful at this stage. Each of them reinforces better 2-way connections between your engineers, your customers & market, and your company mission. Done well, they can dramatically level up your team’s output and focus.

Together, they take about 8–10 weeks to roll out. This assumes someone makes this transition their top priority, dedicating at least 50% of their time and attention. At startup pace, you can aim to get working versions humming by the 6-week mark and then fine-tune.

Let’s hop to it:

Practice #1: The Product Brief

The first practice I recommend is a product brief for every feature or project.

The Product Brief Document:

The product brief covers what it is (and what it isn’t), why you’re building it, and what success looks like. As you shape an idea, it helps you make smarter go/no-go decisions. Once you’ve committed, it provides context and focus for the broader team.

Here’s the Product Brief Template I like to use, based on a Spotify template I can no longer find online. Keep in mind the product brief should include just enough to help you make decisions—no more than 1.5 pages.

The Product Brief Practice:

• Starting today, write a product brief for every idea you spend more than 15 minutes considering or planning. When you’re 75% done, ask 2–3 teammates review it, representing these perspectives: tech lead, UX design, sales/partnerships.
• If someone wants to propose or champion a project, they must write a product brief.
• Use the information in these product briefs to help make prioritization decisions. Deciding not to build something — now or ever—is a win, too.
• Once you’ve committed to a project, but before any work begins, share its product brief far and wide. Designers will have better context for designing experiences and creating assets. Engineers will have more understanding and motivation for getting this done, and be able to make smarter tradeoffs. Sales and marketing will be able to create accurate buzz.

Practice #2: The Internal Roadmap

Post-launch companies will encounter two competing forces. First, you’ll want to do things that don’t scale to delight early customers, so your engineers will be start doing bug investigations and hands-on support. This wreaks havoc on feature velocity. At the same time, you’ll want to scale your engineering team and sell ahead of development to seize opportunities, so you need a reasonably trustworthy way of coordinating work and looking ahead.

This is where a roadmap document and practice can help.

The Internal Roadmap Document:

The roadmap document shows the current state of development plans for the next 3–6 months. This type of roadmap is not for sharing to customers or executives. Its purpose is to improve your internal work and estimates.

Here’s my Startup Roadmap Template. I prefer to keep tooling very light, using Google Sheets rather than a dedicated roadmap app, and no automatic rollups from GitHub or other issue trackers. In my experience, it doesn’t really take that long to update, and getting my hands dirty keeps my finger on the pulse of what’s going on. Others may choose differently.

The Internal Roadmap Practice:

• Set aside 2–4 hours to create your initial document.
• Commit to a biweekly or monthly routine for your tech lead & product lead to review and update the roadmap together. Add it to the agenda of an existing meeting, or schedule a separate time.
• When you meet, start by looking back. What happened in the last 2 weeks? Did you work on what was planned, or did distractions happen? What types of distractions? How long did they take?
• Then, look forward. Are your projects still accurate? Do all the projects for the next 2–4 weeks have designs completed? Should people start installing databases locally or reading architecture docs? If a project requires a specific expert’s time, do you need to block that out now? Is everyone going to an important conference or offsite where you won’t realistically get coding done?
• When you’re working on this document, take off your visionary hat and put on your fact-checker hat. Think of it as accounting and forecasting for team productivity. Bore yourself now, to save panic later ;)
• The roadmap is a doc that you don’t need to push to individual contributors too often. Just leave it openly available for reference.

PM: “How long will it take to make these changes?”

Ambitious Tech Lead: “Two weeks. We can do it next week.”

PM, Before: “Okay, I’ll tell sales to tell customers that it will launch in 2 weeks.”

Two Weeks Later: “Crud. It’s not done yet.”

PM, After: “For the past 4 weeks, we’ve spent about 1 engineering day on hiring and 1 engineering day on tech support. Plus we have PandaConf next week. So it will take a little over 4 weeks before we’re done, but we need it in 3 weeks so let’s figure out how to reallocate time or slim down the work.”

Practice #3: The Strategy Story

The first two practices are internal-facing, but now we’re ready to stitch the story together.

The Strategy Doc

The strategy doc covers market, data, personas, critical needs, and what you’re doing about it. I usually choose a broad title such as “X for 2017” or “Z Strategy Review”, reflecting how comprehensive this doc should be. This will explain market & customer forces to your product team, explain product forces to your marketing & sales team, and tie it all together.

This will almost certainly be a slide deck, but I’d love to know if you can get another format to be equally effective. I don’t have a good non-confidential example to share at this point, but hope to share one in the future. In the meantime, here’s how I think about building the strategy story:

• State the obvious: What is this product, what does it look like to users.
• Facts: Sales or adoption numbers to date, customer feedback, qualitative data, history of the product.
• Analysis of those facts: Takeaways, themes, personas, and more.
• Recommended strategy: Given this landscape, how will you win?
• Plan for getting there: What you’ll ship each month or quarter to get there, and the resources you’ll need to do it.

What separates a good strategy doc from a great one? Like a great story, a great strategy doc will intrigue and delight (amazing opportunity right now, let’s go!), or shock and dismay (we’re doomed but here’s how we’ll fix it). Make this story interesting by digging deep into your facts, assumptions, and beliefs. Often, the writing process will uncover new insights.

The Strategy Practice

• First, take several large chunks of maker time (1–2 days’ worth) to write to 75% done. Next, share it with a group of 2–4 leaders for feedback, other contributions, and first impressions, and edit again.
• Then, sing it as loudly and broadly as you can. This should be your team’s fight song and north star. Share it with all your engineers, designers, marketing, sales, and support. Take the time to do this live, listen for any confusion or questions, and use those to refine the document.
• Of all 3 practices, the cadence of this one is the most variable. You’ll want to write and share a new strategy story for every major shift or evolution in strategy. This could be quarterly, yearly, or something in between.