In Part I we looked at organization theory, determined that a classic hierarchy wasn’t what we wanted, and discussed what marketplace-style organization model could do for us. So what does this look like in practice? Let me introduce you to the Check-in Meeting.
The Check-in Meeting is a venue for reviewing and socializing relevant information about product development efforts. It takes the form of a recurring meeting on a fixed cadence with a queue of topics in three categories:
- Product Plan Review : Present a new project plan or new phase/initiative of an existing project, to propose alignment with an existing strategy and prioritization
- Progress to Plan : Measure a project against stated milestones and goals, in order to secure or retain allocated resources
- Strategy Review : Periodic review and debate of top-level product strategy among CPO and directors, informed by data from recent PPR and PTP topics.
Product teams propose specific topics in these categories through their Directors (a little program management works well here as lubrication) and only the people directly involved in those topics need attend. With the exception of Strategy Reviews, anyone is welcome to listen in on the Check-in Meeting topics.
Strategy reviews are likely private to leadership and its staff, but will pull in relevant product managers and engineering leaders as needed. Think of these topics as coming at the end of the meeting, and on a slower cadence than the check-in meeting itself.
This model has key characteristics that align with our principles from Part I:
- Asynchronous : design and development do not wait on reviews and approval, enabling more activity than could be explicitly managed.
- Interrupt-driven : results and new proposals trigger discussion, inverting the classic model of scheduled reviews
- Strategic : control is exerted through resource allocation rather than tactical approvals, nurturing on-strategy efforts but allowing off-strategy innovation to compete
Here are some examples of check-in narratives:
As a product manager, I’ve been developing a product that I want to formally socialize with the product organization in order to get strategy endorsement. My director agrees and will schedule a Product Plan Review in an upcoming check-in meeting; in the meantime I’ll put together briefing materials that cover my PRD and progress.
As a product director, a project under me is growing and needs additional resources. I’ll have the project team put together a Progress to Plan report for an upcoming check-in meeting, so they can make the case for a shift in investment.
As the VP of Product, I want to reiterate my product strategy to my directors, and find out if anyone has new data that should change either the strategy or my resource investment plan. I’ll cover this in a Strategic Review in an upcoming check-in meeting, and I will expect my team to come prepared with relevant data and metrics against project KPIs.
As a product manager, I noticed an upcoming Product Plan Review for a shared service I depend on, so I’m going to attend the check-in meeting in order to stay informed of changes in their plan.
So how do we plan an actual org structure that reflects the Check-in Process? We’re intentionally avoiding building an authority hierarchy, because they are inefficient at meeting our goals. Don’t be fooled though, we still need an organization to support growth – we haven’t eliminated the need for good staff command practices. Therefore, I want to talk about the role of the Director in our marketplace model.
Senior product leadership is responsible for defining and evolving product strategy across the organization. In order to keep from being a bottleneck, executives must delegate the responsibility of putting strategy into practice to a staff of Directors.
With the Check-In process, Directors own prioritization of projects in their divisions, and either directly allocate resources or use that prioritization to inform engineering how to do so. Directors also carry the administrative load of reviewing their departmental product plans, identifying the need for Product Plan Reviews and Progress to Plans, and officiating the Check-In meeting itself. As load increases, the number of directors should be increased to compensate. As activity outgrows the existing structure, the Check-In Meeting itself may be deployed inside each Director’s organization to drive complexity further down the stack.
Do you know what kills more development methodologies in practice than anything else? Rollout. Implementing process change is hard, and should be approached mindfully and with a little healthy fear. However, our marketplace-style approach is well-suited to installation in existing environments, because it is intrinsically a recruit-and-influence methodology. A typical rollout looks like this:
- Create a hospitable environment: Institute the check-in meeting and make it voluntary, but halt new resource allocations except through the Check-in meeting.
- Seed the market: Jumpstart adoption by giving resources to the first few projects that land decent pitches. Apply a generous hand here, as everyone is learning and the process has yet to establish a rhythm.
- Early adoption: The siren song of resource allocation combined with the pinch of projects outgrowing their current staff drives teams to the Check-in meeting. More participation = internal competition and rising quality. As resources are consumed and become scarce, Product Managers start bringing higher-quality content and standardizing on what works in order to win.
- Full throttle: With heavy participation, enough information on what projects are successful is flowing in the Check-in Meeting to expose new insights. Strategy begins to be influenced by project outcomes in a feedback loop, and Directors get increasingly invested in participation.
- Scale-up: As activity outgrows the existing management structure, additional Directors may be added, and check-in meetings may be deployed inside a single directorship to push complexity down
Let’s recap: we started out by looking at what is fundamentally a maturity problem : how organizations grow and scale without losing the innovation and nimble execution of a single-product startup. (Organizations failing to do this is what makes product management far less fun in big companies!)
In Part I, we looked at a command-and-control organization model and rejected it as too slow and not adept enough at identifying and nurturing innovation. By applying a little fundraising experience we established a Marketplace strategy to reframe how we make product portfolio decisions. And we talked about a concrete process in Part II that supports implementing our Marketplace-driven organization.
Give this a try – if the history of software development teaches us anything, it is that regardless of technology or implementation, it’s the way the organization thinks about harnessing great ideas and the individuals behind them that determines success in the long term.