Recently, a young, successful tech company asked me to come up with a product planning model for them. I started out by listing off what was already working for them :
- Internal entrepreneurialism
- Building projects around small teams of motivated individuals
- Dual-tracking : small teams for products and separate ones for shared, core components
Then I listed six key goals that are difficult to achieve when you’re newly successful and growing fast:
- Keeping leaders informed of everything that is going on
- Getting line-level product managers onto a consistent process
- Adjusting top-level strategy based on what is working
- Identifying what innovation to nurture among all the activity
- Discovering shared components that are in decline
- Investing mindfully across short, mid and long-term projects
If we want to add that second category of ideals to the mix, it will help to first take a step back and look at Product Management in general.
You can distill product management down to two core questions: How we will investigate, design, plan and build a product; and how we will manage our portfolio of product efforts according to our strategy and within our resources.
These problems are separable – solving for one doesn’t impact the other – and we can set the first problem aside, since it doesn’t change with scale. (Also, a successful organization probably has one or two good PMs already!)
The second problem – managing a portfolio of efforts to a strategy and with a finite resource envelope – becomes more challenging as the number of efforts grow, and that’s why it’s interesting to us.
Classic command-and-control organizational strategy would solve this problem of scale through building a hierarchical organization, implementing an approvals-oriented product life cycle, and applying bucketloads of program management. This approach conserves development resources through prioritization and gives great control to senior leaders, but it does so at the expense of both product team speed and management bandwidth. Additionally, new growth is stifled due to the effort required of a single initiative to navigate the approval hierarchy. In fact, this approach favors growing large existing projects (because they are already approved, understood, and funded) rather than creating new lightweight ones. This is the opposite of what we want!
Product lifecycle processes are typically used by management to explicitly approve effort, and to ensure that effort is on track and on time. What if we are less concerned with spending resources or ensuring strategic alignment, but more concerned with strategy development and nurturing innovation? We can disrupt the approval relationship, and use a product lifecycle process as a marketplace for groups to publish outcomes and solicit additional resources from leadership.
“Classic command-and-control organizational strategy would solve this problem of scale through building a hierarchical organization”
Let’s not forget the bucketloads of program managers either – without our hierarchical org and complex review process, we’ll drown in activity if we don’t plan for it.
- Make it cheap to try : Enable builders to start working without navigating complex review processes. Product manager has an idea? Tell her to go recruit some peers and test it! Don’t ask motivated individuals to pitch to a VP or prove a business case before trying something out; match procedural effort with cost and save the reviews for when there’s a significant resource ask on the table.
- Attract relevant insight : Draw data into the management process through incentives, rather than mandating periodic reporting. Every PLC I’ve worked within included a fair bit of progress-to-plan reporting and mandatory review meetings, but mandatory reporting has very poor information content. We can improve the signal-to-noise ratio considerably (and reduce the need for program management cycles) if reporting is done only as part of an activity that directly benefits the project itself.
- Endorse, not dictate : Guide projects through investment and strategy leadership, rather than direct approval and management. This is the obvious next step for internal entrepreneurialism – senior leaders who function like VCs rather than managers. Your VP has a strategy in mind, and a pool of resources to make bets with along that strategy. Create a pitch meeting! Projects that have momentum will attract investment, those in decline will naturally lose it. And outliers that succeed despite being off-strategy feed data back into the correct function for senior management : defining and maintaining strategy. Plus, the load scales with the number of growing projects, not the total, so effort is significantly reduced.
So far, we’ve outlined a list of attributes we want in our organization – nimbleness, informed leaders, a means to identify successful outliers – and we’ve defined three strategies that differ from traditional organization theory that will support our attributes. I’d represent it visually like this:
This marketplace product lifecycle process looks a lot like the startup ecosystem. Product managers participate in order to secure investment and resources. The most active and on-strategy projects rise in visibility and attract resources, and savvy product managers stay engaged in order to keep informed.
As projects decline, they naturally drop in visibility and therefore investment for future development. Disruption has its place, too – off-strategy projects can still execute and if successful will influence strategy in new directions.
Hierarchy between product teams and strategic leaders is pretty flat – we will put as many directors between senior management and product teams as required for good staff coverage, but we don’t need an approval hierarchy. In fact, this model works well even where no product team members actually report to product management – “resources” in that case are just project priority and the model still functions seamlessly.