The Art of Strategic Product Management
Why high growth startups need to build less, not more.
This is part 1 of a 2-article series (part 2 is here)
Gillian is the first product manager at a fifteen-person startup that just raised a $5M Series A round. Having spent years in the startup trenches, she’s technically competent, meticulous, and a great communicator. She’s a Type A product manager, and she’s up for a challenge.
She needs to be. Over many late nights, Gillian has been wrestling with how to prioritize the many directions she is being pulled in: by customers, salespeople, her Q&A team, and her engineers. Should they add a new product extension to target a new, possibly attractive, customer segment? Should they build an API so they can integrate with partners? Should they attack the backlog of feature requests from existing customers? Or, should they do all of the above at the same time (what her management team seems to prefer)?
She has a million requests and no time to be strategic.
To cope with the ever-growing product roadmap, Gillian is determined to roll out as many features as physically possible. The goal is fifty by the end of 2018. That’s how they will steal market share from their competitors, right?
The problem is, this is not the path to maximum growth.
Even if Gillian builds fifty new features without any bugs this year (absolutely impossible if you’ve ever built anything before), her startup may still lag behind. They won’t grow as fast as CarGurus, which didn’t have a product manager until they were well past $100M in growth. Or Klaviyo or Paint Nite or Twice. How are companies without any dedicated product managers kicking the butt of those with amazingly talented, by-the-book PMs?
I know what it feels like to be Gillian. Because I was her in some regards when I started my career as a young, impressionable (aka, clueless) PM. I believed that the more features from my roadmap, the more I was winning.
Over time, I’ve found a different path that was drastically more effective, and this is what I’ll share with you now. I call it The Way of the Lazy Product Manager.
The Lazy Product Manager challenges the sacred cow of relying on more and more amazing features to “growth hack” your way to billionaredom. It’s ruthlessly focusing on “do less, not more.” This alone is already blasphemy to the Type A product manager. How could you possibly do less and not more?
But, the Lazy Product Manager is not just about doing less. It’s about doing what’s strategic. And not being strategic has been the Achilles’ heel of many great product managers. It’s only when product management is aligned with market orientation that a product can truly succeed in the market. Above all, it’s only when you focus on doing less and doing what’s strategic, that you can focus on what will have the most impact.
Here are the 10 principles of the Lazy Product Manager:
Ignore your customers. Yes, you still need to listen to them, but the Lazy Product Manager does not chase after every customer request. Instead, build the minimum feature set to keep them happy — and paying. To be honest, if your customers refuse to sign up, and instead send you chasing one new product feature after another, it is a warning sign that the need you’re addressing may not be pressing enough.
Building less is more. If I haven’t made it clear in the intro… no! It’s not more features, it’s the RIGHT features. How do I figure out the right features, you ask? Now you’re thinking. Start with this question, rather than adding willy-nilly to your roadmap.
Validate your business, not just your product. This is where PMs and, well, everyone on the business side typically diverge. But, the reality is that your elegant, brilliant, or adorably quirky product is a funded side project, unless it’s the core of an actual business. So, user test all you’d like, but remember that even the most detailed customer feedback session will not give you a business model. There is no “if I build it, they will buy.” (I know, someone told you this once. They lied.) You must figure out whose urgent or actionable need your product solves. The earlier you sell, the higher your chances of figuring out if your product will do this for someone. As I’ve argued elsewhere, your customers might have valuable input for you (like price considerations or install requirements) that you might not hear if you’re not out selling quite early. In other words, sales is not something you should tack on the end of a lengthy product development process. And TLDR, this is what the entire “Lean Startup” movement was about — so if you want to go deeper, go read it.
Don’t build, sell. Is this you: every time you face a sales objection, you build a new feature (or product line)? Product folks, be honest! I know, it’s hard. Makers gonna make, right? When you’re just so good at building stuff, you sometimes can’t help yourself. But this is also why teams with too much A) product talent, B) engineering talent or C) money sometimes take too long to find a product market fit. They’re not asking the hard questions early enough, like “Is this valuable enough that someone will pay me for it? Or, invest time using it every day?” As an incredibly successful founder friend once said: “At the end of the day, you just have to sell something to someone.” This is why salespeople sometimes make better PMs than career PMs. They are the epitome of the Lazy Product Manager. It’s also why we have argued elsewhere that early stage companies don’t need PMs.
Forced prioritization. I love this fantastic anecdote from Pandora (although 40 engineers — whoa): “What would be stupid for us not to do in the next 90 days?” Ideally, you can count sprint targets on one hand. Here are all the reasons this is a great idea: A) less complexity, B) prioritization forces you to be strategic, C) that’s enough already.
Step into the matrix. How do you decide which features to build among the gazillion requests? Start by classifying product features into engagement, revenue, utility and ease of use/delight. Build a matrix of requests organized by category, a second excellent lesson from the Pandora team. Once you do that, get your key stakeholders to agree on dollar values for each category (the Lazy Product Manager prefers numbers because there’s less arguing in meetings.) Finally, decide on some breakdown or prioritization among these for the year, spend your dollars and be done with it. If you’re spending time on a fourth order product request, the reality is that no one is coming to give you a medal for it. There are no brownie points in adult life.
Own, don’t get owned by your tools. Asana, Trello, Jira — whatever systems you use to keep the trains running — the end goal is the same. Clarity, clarity, clarity! Aim for minimal communication (and minimal systems) beyond what you need to achieve it.
Communicate like a 3-year-old. Preschoolers communicate with stories and numbers. Invest in learning how to speak data. Rather than sending long batches of text back and forth with your team, try taking a week where you just send out data along with takeaways and annotated screenshots/wireframes. I bet you’d be more effective immediately.
Copying is encouraged. Talk about sacred cows. But, of course, copying is an essential pillar of the Lazy Product Manager’s playbook. Facebook has shown how lazy product management paired with scale and good business sense can be a successful strategy. Designing products has touchy-feely moments, but startup success is often the result of a brutal competitive war — and you’d be foolish not to recognize that sometimes there’s merit in copying what’s working for competitors. As long as it doesn’t hinder the product in some fundamental way, there are many areas where seeing what works and stealing it makes the most sense. If you don’t want to do it yourself, at least recognize it’s likely to happen to you (see examples from Apple, Snapchat, Google, etc.)
Admit failure (and move on). What are the signs of early product failure? No one is buying your product. No one is sharing it with their friends. Users are logging in and immediately logging back out again, never to return. The Type A product manager thinks: “It’s not you, it’s me? Can I get you some new features to convince you to stay?” Meanwhile, the Lazy Product Manager readily admits failure and moves onto the next product. The Type A product manager could learn something from this approach. Remember not to watch the lips of your focus groups, watch their feet instead: what customers actually do in the wild. You can chase, educate, and reiterate, but if you’re not meeting an easily articulable need for customers, you risk spinning your wheels.
Making the switch to the Lazy Product Manager’s way will not happen overnight. To get started, jot down your answers to three questions.
What is strategic for your organization? Validating customer demand/a path to sales/product market fit? Growth: of customers/of partners/of revenue/along a specific dimension of engagement?
What that you build will move the needle?
What is your product team doing right now that won’t? (This is the toughest question: be honest!)
When you’re done, go take a nap. Call your mom (or your SO). If you insist on plugging back in, call a potential customer. Whatever you do, don’t build anything new — yet. Take some inspiration from the cartoon below:
Remember: a path to sustainable, scalable growth matters more than an elegant product, and your job is to get out of the way, AND help your company figure out what you build will actually have the most impact (more on the latter in the second post in this series.)
So, are you Gillian? If you’re still tempted to build yet another feature, tweet me at @parulia and I’ll talk you down. And may the growth forces be with you, my friend.