PMs should focus on “best fit,” not “best practices”
The web is flooded with product management best practices that come in the form of blog posts, podcasts, PM-specific websites, training…
The web is flooded with product management best practices that come in the form of blog posts, podcasts, PM-specific websites, training materials, and much more. I’ve derived much personal benefit from these materials, but most of them neglect to mention an important nuance: best practices change depending on the situation.
When I joined Cockroach Labs, I was the first product team hire. The company had previously been composed of a large engineering team supported by one marketing person, one new design hire, and one recruiting person. Product was largely led by the co-founders. I brought with me many unrealistic expectations of what the product organization should look like. Having worked in venture capital before, I learned best practices through observing the portfolio companies I worked with, speaking to startup entrepreneurs, and (it hurts me to admit it) reading articles from thought leaders in the space.
When I first started, I tried to implement some of these best practices, specifically around task management, user stories, usability interviews, etc. Looking back, I was really throwing things against the wall to see what stuck, and nothing stuck. My biggest mistake was thinking that I could force fit best practices in an effort to bring efficiency and structure to the chaos of working at a startup without focusing on the foundational concept of PM 101: understanding the “why” of everything.
Understanding the “why” is important because the value of any solution is driven by context. For example, consider the scenario where a product management team proposes Jira as a solution, but without providing the context that inter-team communication is falling apart as the company is growing. It’s hard to message the value of the solution to the rest of the team, and the product management team is bound to experience strong pushback. On the other hand, perhaps the company isn’t large enough to merit using Jira, and simply offering up Jira as a solution would force an overbearing solution where one isn’t needed yet. Ultimately, what is considered a best practice depends on the stage of the company (mature vs startup), the culture (flat vs hierarchal), product development cadence (agile v scheduled releases), etc.
Specifically for me, the company was still in beta and very early in product development. Task management didn’t make sense yet since we were focusing on improving stability, and there weren’t issues around scoping, feature definition, and prioritization. Everything we were working on was crucial to the product functioning correctly. User stories around specific features didn’t make sense because we hadn’t fully defined who our users were and why they needed our database. Usability interviews were less impactful because our user base was still early in adoption. As a response to these findings, I chose to take a very different path from what one might expect from a PM. You can read about it further here.
A Framework for Determining Best Fit
With the benefit of 20–20 hindsight, I’m now aware that I should have focused on finding the best fit solution rather than implementing best practices that didn’t apply to the situation I was in. As the only member of the product team, I was also limited in capacity, so it was very important to focus on the right things. Here’s how I would have approached the situation if given a second chance.
Step 1: Define the problem statement
What is the problem and why does it matter?
Step 2: Quantify the potential impact of finding a solution
What are the key issues the business is currently facing?
Is there a business reason for finding a solution? Is there a technical reason for finding a solution? Is there a cultural reason for finding a solution?
What would be the business impact if you addressed this problem?
What would be the business risk of not addressing this problem? What are you taking time away from?
Step 3: Define your current “state”
What is the culture of the team?
Who are the stakeholders?
Who could be a blocker?
How much influence do you have in the team?
Is this a priority for multiple teams, or just for you?
Step 4: Figure out a solution that matches the scope of the problem
What is the MVP? What is the least you can do to provide the biggest impact?
Step 5: Is the solution worth doing?
How urgently is a solution needed?
How long will it be used? When will we outgrow it as a team?
How much maintenance overhead does it require?
Execution
Now that you’ve figured out a best fit solution, it’s time for execution. When executing, it’s important to remember that startups are fast moving, and that it is okay to pivot. Don’t keep churning on solutions that aren’t working out, and don’t over-optimize once an adequate solution is achieved. At the end of the day, as long as you remember the “why” and scope out a project that takes into account the state you are in, you’ll save yourself from the thankless exercise of trying a bunch of solutions that don’t stick with the team. Time is limited, so it’s always better to focus on high impact projects that move the needle in a tangible way.