What You Need To Know From Day 1 To Your First VP of Product
the original talk
As an early CEO, the first thing you need to know about Product Management is that you already have a VP of Product: you.
In the absence of a long term Product leader, the CEO is the VP of Product (and Finance, Marketing, HR, …). This is true even as you hire individual contributors to support the function.
I make this point not to freak you out, but to let you know that you’re going to be doing this job for a while. It’s a very important function, so it’s worth being thoughtful about your approach.
The second thing you need to know is…
A little bit of chaos is stage appropriate. Much of what drives a long term successful product strategy is knowing who you are and early stage companies have no idea who they are. The goal is less chaos over time. Attempts to wipe out chaos completely tend to lead to a lot of slow BigCo. process.
First Principles
Whenever I meet a product manager, I ask them this question, “How does an idea become a product at your company?” That’s it, that’s what Product is. It’s the ownership, execution, and constant improvement of the process by which you adapt and deliver products to the market.
Early in a company’s lifecycle, there’re a lot of things to build. Stuff you’ve always wanted to put into the product that keeps getting put off. Burning issues. Near term, potentially lucrative opportunities. Everything is either gold or on fire and sometimes it’s both.
So how do we know what to build? How do we get a perspective on this today and how do we grow it over time?
Step 1: Separate Evaluation and Execution
Most early stage companies lump all these things into a list, do some loose ordering of the top few items, and point the engineering team at it. When I ask for a look at their roadmap, founders sheepishly point at this list.
It’ll look something like this:
Change sign-up button copy
Investigate using a blockchain
Add profile pictures
Build an iPhone app
Integrate with Salesforce
There’s nothing inherently wrong with this list of features. It’s not hard to imagine a company for which these would be the most critical things they could build and the order that they need them.
But this isn’t usually case. It’s usually an untended hodgepodge, often including a few things the CEO will readily point out they’ll never build.
The inherent problem of this list is that it’s a free-for-all. Things went right from idea to approved project without critical thought. So step one is to separate the process of evaluating a feature and the process of prioritizing work for the development team.
The tool you use to do this is irrelevant. I’ve used Google Forms and Sheets, Jira, Aha!, they’re all fine. The goal is a zero loss system, not really fancy software. Feature ideas are developed and considered before being rejected or passed through to the development team.
Step 2: Prioritize
So now you’ve got a list of things you’d consider and a list of things you know you want to build. How do you order them?
What you’ll find is that it’s pretty easy to prioritize burning issues and hard to prioritize strategic projects. Why is this?
The problem is that we often try to assess product decisions strictly within the domain of Product. This feature vs. that feature, this customer’s input vs. that customer. Strategy goes out the window.
What we’re observing here is Flatland.
Two-dimensional shapes live happily in Flatland, a flat plane.
One day a visitor comes. The inhabitants try to interact with it on two dimensional terms.
But they couldn’t understand when their visitor explained that it was a “sphere” living in a strange third dimension.
Company strategy is multi-dimensional and a product-centric prioritization process is flat. You will always struggle to deliver strategic capabilities without the connection to a broader company strategy.
The Real Step 2: Find Yourself
Companies spend a lot of time and money on those big fancy unicorn mission statements. There’s a place for big and bold, but it’s sufficient for early stage companies to write down a simple positioning statement.
For [your customers] [your company] is [tactical service definition] Better than [competitors] Because [reasons]
Your customers: who are they? Is it a big company? Small company? Person with a dog? Dog with a robot? This sets the boundary of effort and defines succinctly the types of customer you’re going to listen to.
Tactical service definition: what do you do? Be as specific as possible, “we host a website and mobile app that does X.” We provide software and services around Y.
Competitors: list them out. Be honest. Be comprehensive. We often think of competitors in terms of companies that do the same things we do, but competition may just compete for time, attention, or budget from the same buyer.
Reasons: what makes you special? What do you do better? Pick your top three strategic advantages over the competition.
One framework I like to think about here is from The Discipline of Market Leaders by Michael Treacy. To summarize, your company needs to be good in all of these areas, but excellent in one:
Operational Excellence — the company is extremely efficient at resource (mostly money) utilization. examples: Costco, on-demand delivery companies
Product Leadership — the company has the very best product and an almost supernatural ability to deliver products users will want before they even know it. examples: Apple under Steve Jobs, most startups early on*
Customer Intimacy — the company has an extremely close relationship with their customers, exceptional support, and offers a variety of products to cater to individual customers needs. examples: Nordstrom, Zappos
To be successful, Treacy says, companies need to be commensurate in each area, but excel in one. Which is your company and how does that make you competitive?
Reminder:
You don’t need to know all of these things right now, even the process of developing them will provide a lot of clarity for your organization. Bonus: you need a lot of this for your pitch deck anyway.
Step 3: Set Goals
The last piece of the strategic puzzle is to set a near term goal. What does the company need to do in the next six months?
“We need to serve this new market.”
“We need to establish ourselves as leaders in the space.”
Be careful here, early stage companies may lurch from zero plans to an OKR process designed for 10,000 person organizations. The minimum requirement is a company objective you can use to frame what the product should look like in three to six months.
Step 4: Categorize
Sub-goals line up naturally under your top-line company goal and you can start to see where those strategic features fit.
And now, nested under these subgoals with scopes and target dates, you can understand these multi-dimensional features.
Step 5: Now Prioritize
Now we have a framework for understanding and reasoning about our three dimensional strategy alongside two dimensional tactical features. We have a list of things under consideration as well as a list of committed work. You can reason about the work that needs to be done by when and balance it against near term revenue targets.
If you get within spitting distance of this before your first institutional investment, you should be proud of yourselves. Plenty of CEOs of public companies fail this test on a daily basis.
And, remember, it’s a huge benefit in fundraising to be able to articulate:
Who your customers are
What you’re doing for them
Who you’re competing against
Why you’re going to beat them
What the company needs to do in the next six months
And how that drives near term product objectives
There’s one last layer to prioritization, though. And as we progress from just before to just after our first institutional investment, our team grows. Larger projects that we could never get to are suddenly possible, but we’re still very resource constrained.
Step 6: Estimate
To continue to emphasize speed to impact, you need to balance priority against the level of effort. Estimates are somewhere between mandatory and the devil incarnate in the world of software development, depending on who you ask and the time of day. So this isn’t that.
What we’re looking for are t-shirt sizes: small, medium, large. Against our feature priority, small high priority projects should be done first. Large low priority projects should be tabled indefinitely.
This is a top down product plan. In a more developed system, you’d then build up estimates from Engineering capacity and use that to sketch out a roadmap. That is a lot of work and requires an amount of rigor in the development process that would merit its own talk.
Step 7: Roadmap
Your engineers won’t love it, but squint enough at those t-shirt sizes and they can be very rough estimates. You can use those estimates to fit features into quarters and deliver something like a roadmap slide deck. In the absence of a better estimation system, commit to far fewer things than seem possible in a spreadsheet. Think half.
For roadmap slides, I like to articulate the value being created for the user and leave the specifics loose enough to allow for changes resulting from research. An extremely simple picture and a handful of bullet points are enough.
Step 8: Execute
From here, your product managers will have a rough plan of the value they need to deliver. They should be conducting research, working with design/UX, and refining scope with Engineering.
Founders often ask how much they should be documenting those early features? Usually they say this because they communicate several weeks of work with the subject of a single Jira ticket.
No judgement if you’re a busy CEO and the most you have time for is a whiteboard with the engineers some weeks. When you have time and PMs to support you, larger projects should be documented for both the project team and future PMs.
For a user-facing project that’s going to take more than a couple weeks. I want to capture:
Goals of the projectMetric benefitsGrowthEngagementMonetizationProject teamScreenshots and bulleted lists describing critical functionality (less is more)
Step 9: Scale
We’re now getting pretty far past that investment, if you’re having a panic attack over the amount of work I’m asking for. You’ll have help!
But the next question is, what kind of help do I need? Should I add individual contributor PMs or bring in a leader? Should I split the difference and get a director? And who do you hire? A senior PM wants a path up, but product teams grow slowly and the board will want you to bring in someone more senior.
These aren’t easy questions.
My rule of thumb is one PM to 10–12 engineers.
Pre-product team, think about how much founder time you’re capable of devoting to the job. If you can put in half time, you can keep five engineers busy.
If you only have 25%, your development team’s going to be underutilized with three.
When you think about VPs of functions, you probably think about that person running a large team, but Product teams grow slowly. Early Product VPs may often manage teams of two to four. There’re a few reasons you might consider when you’re thinking through scaling your Product organization:
Complexity — certain product categories and technologies may be so complex that they require a high level of coordination
Enterprise Sales — when Big Co. buys from a startup, they’re investing in the roadmap and want to hear from the VP of Product on a regular basis
High Growth — obviously, if the team is scaling rapidly, you want an experienced leader to build the function
Domain Expertise — founders are often concerned about their experience asymmetry with large incumbents and want to poach an expert.
There’s a lot to be said about finding the right VP of Product for you, your market, your user and customers. Suffice to say, this person’s job is to manage this whole funnel from idea to delivery, optimize it, and layer in ever better sources of data and feedback. All while building a team and representing the company internally and externally.
The person who can do that wants you to…
Step 10: Give Them A Little Space
It’s hard for a CEO to give up any control, but you’ll hurt the product team’s autonomy and ability to execute if you drop in with a lot of opinions that aren’t based on understanding their work. Here’s roughly how often you need to be involved to be effective at various stages of development:
You need to figure out what level of input works for you and your new leader.
Putting It All Together
To scale your product strategy from day 1 to hiring your first VP, you have to:
Separate Evaluation and Execution — slow down, consider what you’re doing
Find Yourself — understand your position and what will make you successful
Set Goals — figure out what you need to get done in the next 6–9 months
Categorize — group strategic features by their importance against your goals
Prioritize — now stack your strategic features against burning issues and revenue opportunities
Estimate — balance level of effort against priority
Roadmap — communicate themes and map the most critical features to quarters
Execute
Scale
Let It Go!
Shameless Plug
We build these frameworks and facilitate these conversations for a living! If this sounds like something your company needs, contact us here or email drew@productbridge.co.
From my talk at Startupfest for founders about to raise their first institutional investment. Thanks to Cindy Alvarez for the introduction to Rebecca Croll and to Rebecca and the whole Startupfest team for an amazing event.