A particular pattern emerged for me from a series of conversations with clients and peers this week: Effective product teams understand the consequences of their choices and act accordingly instead of chasing best practices. Let me explain.
Lately, I have seen more messaging emerge around what’s “right” or “wrong” in the domain of product management. “You’re only a real product team if you’re only working on Outcomes!”, “You have to talk to customers every week!”, “You have to complete this statement to have a product vision!” And so on.
So, while it’s easy to compare your team’s chosen strategies and tactics with said “best practices,” I believe that something else is more important for product teams: Understand the consequences of their choices.
Example: Product Strategy
There’s no shortage of Product Strategy templates out there. But what are the consequences of following the convention of using a “gap text” to define it? You will probably have an easier time communicating a set of concise sentences and can pull it up easier.
But the lack of context about how you arrived at said strategy cornerstones will lead to a lack of buy-in from team members. If that’s not your goal, run with it (but I doubt it is). In addition, simplified sentences don’t work well for pointing out the gaps in said strategy, dependencies, and relationship of Strategy inputs, and what strategic tracks you will follow, which is essential to turn your strategy into tangible priorities (not features!) for your teams.
Example: OKRs
OKRs are a powerful vehicle to help product teams (and organizations) experience a wide variety of benefits. But a lack of clarity of what benefit matters most to YOUR team can stand in your way of coming up with OKRs that help you to measure progress.
And In an ideal world, an effective Key Result ticks three boxes:
- It’s influenceable by the Product Team that came up with it
- It changes at a cadence that allows the team to react and adapt its priorities
- It describes a change in behavior rather than a task or feature
But product teams might not be in the privileged position of finding all three criteria met by their drafted OKRs. And, after all, what’s the point of setting and measuring a goal that checks all the boxes of being an Outcome but doesn’t help you adjust your actions along the way?
If your primary goal for using OKRs is to shift people’s mindset toward Outcomes, then, sure, a lagging Outcome KR might do the job. But suppose OKRs should be used as a practical tool to measure progress and adjust priorities continuously. In that case, you need to identify more leading indicators to avoid getting stuck with your KRs.
And whether that leads to a more Outcome-ish or Output-ish KR should only depend on what type of Key Result helps you in your everyday decision-making.
Example: Product Discovery
I’ve written before about the fallacy of focusing on an artificial number of Discovery activities as a substitute for consciously choosing the proper techniques that help you make progress right now. The most successful product teams indeed seek honest interactions with their customers through quantitative and qualitative research.
It’s also true that they collect signals about the usability, feasibility, and desirability of an idea without investing too much time into writing code. But that doesn’t mean that “testing 20 ideas per week” or “talking to one customer every week” is YOUR path to success.
Instead, a focus on hitting these numbers can lead to things like an opportunistic selection of user problems, questioning choices over and over again, and singular case decision-making. All of which are hindering your work more than they help you.
This is not an excuse for acting based on gut feeling alone. It’s a nudge for taking a hard look at the evidence you have and making conscious decisions based on that.
Have it your Way
If you’re an organization with the same culture, traffic, team structures, business model, and decision-making processes like the one you spotted a best practice from, give copying it 1:1 a try. If not, have the ambition to make it your way by looking at the consequences of a best practice and deciding if it’s worth it, or if you can find and use an alternative that leads to the same results for your team.
Speak soon,
Tim
Content worth your Time
Beating the drum of your product strategy tune by Megan Murphy
She decided to turn Good Strategy/Bad Strategy into a Trello board for her as-yet undeveloped product strategy, its main challenges and a coherent action plan. In the talk she runs through how she set this up. “Take an honest look at the challenges around you and articulate the main ones you need to overcome in pursuit of your goal,” she says. It’s important that you not only articulate what you will do but also what you won’t do, she adds.
What metrics are the most important for your product?
To help our product partners answer these questions, we use product usage concepts that, over time, have become well understood and agreed upon throughout the company. These terms can be directly related to key points during a customer’s journey within our product:
- Intent to use: The action or actions customers take that tell us definitively they intend to use the product or feature.
- Activation: The point at which a customer first derives real value from the product or feature.
- Engagement: The extent to which a customer continues to gain value from the product or feature (how much, how often, over how long a period of time).
How Twitter Applied the “Jobs to Be Done” Approach to Strategy
This was done via workshops in which company leaders evaluated the list of jobs by criteria such as how widely they were shared by customers, the expected value of solving them, and where Twitter had a compelling and differentiated solution. The result was alignment around three priority jobs for Twitter consumers: “inform me,” “have a conversation,” and “inform others.” Similar work was done to identify the priority jobs of other Twitter stakeholders such as advertisers and the developer community.
Suitably Detailed Roadmap Items
Theme-based/NOW-NEXT-LATER roadmaps are only a real improvement over gantt charts if you acknowledge the uncertainty of the future through less granular details, the more you look “to the right.” John beautifully summarizes this better practice for product roadmaps.