product
op-model
transformation
The Product Model needs to be intentionally designed to be cohesive.
You'll often hear about 'the Product Model' especially in the context of transformation initiatives. But what is that exactly? Won't it just evolve?
Sorry, it won't.
It's critical to design the Product Model so that teams, and the broader organization, understand the mission, their contributions and what success looks like.
You risk, at worst, failing to deliver impact and value, and at best, a trick of incremental wins with outsized costs and delays.
This puts the entire business case benefits to transformation at risk and gives your competition time to win while you figure everything out how to beat you.
What are the key components necessary when you are standing up the Product Model in companies? Here are a few items:
- Product, capability and team taxonomy
- Product Funding of durable teams
- Outcomes, Strategy and Measurements practices to create aligned autonomy
- Dependency: An enterprise/corporate strategy
Product, capability and team taxonomy
To product, or not to product, that is the question. Whether 'tis nobler in the mind to suffer...
What is a product? Isn't part of moving to the product model making everything a product? Again, sorry, no.
A product is a solution that helps the customer get a job done.
What would be a good example of this? In ecommerce, Target.com or the Target app are products that help the customer get a job done.
Well, the Target app actually helps the customer get multiple jobs done, but that is another story for another time.
These need to be further decomposed however. But how?
The common approach is to breaking things down into teams who, in the case of the Target app, Product List Page, Homepage, Authentication, and Search.
The teams are decomposed into software/experience components, because this is about us, we use the term supply side.
This isn't horrible, engineers seem to prefer this approach. Search, for example, is well-defined. We understand the technical boundaries.
In this example, a Search product teaem might be broken down into:
- Search front-end to include the search box, results page
- Backend APIs to include the underlying index and managing the ingestion process
- Algorithms, to optimize search term meanings, etc
- Some are adding voice to this as well
But what about the customer?
The customer winds up confused with a significant amount of cognitive overhead.
They are quickly frustrated as a consequence of designing around software/technology versus the needs of the customer.
Despite the best attempts to solve for this via design systems, you can't out design poor org design.
These teams also quickly devolve to feature teams. Money pits, deserts absent value.
There is a better way: Design the org around the customer needs.
This is the way.
Clay Christensen wrote about in his book "Competing Against Luck". This is referred to as demand side, it's customer-centric.
We experimented with this at Target, well at least part of the product org did.
The difficulties lie in defining what the Jobs-to-be-Done are, and selecting those Jobs to focus on.
A customer might be hiring you for a Job that isn't very important to you organizationally.
Or, an organization may have Jobs with a higher priority or attractiveness ( for a variety of reasons) that are prioritized.
The second difficulty will be in those cross-cutting capabilities who owns them?
These are things like authentication, payments, etc. You definitely need to ensure those capabilities are supported.
A critical practice of this approach is having an 'inner source' model whereby all code repos are open for pull requests from all teams.
I'll write more about this in another post.
The second option is more meaningful in terms of impacting the customer and improving business outcomes.
The model needs to be iterated upon as you won't necessarily get the Jobs correct at first.
There were be a lot of discipline required from product and engineering to bring this to life.
We proved at Target this was the correct approach as judged by revenue growth and NPS scores.
We always wanted to expand this further to include merchandizing, and marketing into our Jobs structure, but wasn't able to do that.
A retailer who does this will clean up as this is what true customer-centricity looks like.
Product funding of durable teams.
This needs to come first, not last.
The opposite of what the agilistas recommend.
They would be wrong. Yes, this is difficult and most agilistas do not understand finance.
You can't build a house on a poor foundation.
Moving to the product model without product funding results in project behaviors.
People move from team to team and no progress is made.
This work should start in parallel with the product taxonomy.
Each team should have the design, engineering, support, content skills as needed to deliver on what the customer needs.
Across the leadership team, and cross functionally, barring an emergency, leaders need to align that the team members won't be changed without a material change in the business or strategy.
Should the environment change, we agree to only consider changing team members every six months.
Change will happen but cross-functional leaders need to align on this.
This allows the leadership team the flexibility to adapt to progress on the business/product strategy in a meaningful timeframe without creating churn on the teams.
A critical component of this is to align the cost of the team(s) and the impact they will drive from helping the customer get the job done better.
If the costs of the team(s) is greater than the value the company is receiving, we are destroying shareholder value.
It helps to have someone aligned or even assigned to the leadership team from finance to help determine the costs.
The impact or value will be an output of the next part where each team will have objective leading metrics to help them show they are helping the customer get the job done better.
Between the strategy and roadmap, this should build more confidence that we've got the right team taxonomy and skills.
We'll also review this quarterly as part of the cadences we build in our Op Model - also covered in the next section.
Outcomes, Strategy and Measurements practices to create aligned autonomy
We've identified and chosen the Jobs-to-be-Done and the customer.
Outside the scope of this post, we have a regular set of practices to help us understand the customers needs and where there's unmet needs.
A set of starting questions:
- What does winning look like for the customer and the business this year?
- What is our investment thesis looking like?
- What Job Steps ( from our Job Map) are we going after?
- Why these and not the others?
- What are the unmet needs? Struggling moments?
- Where are our 'competitors' weak?
- How will this help the customer?
- How will we measure this all?
Measurement. Everyone wants accountability, but no one wants to measure the impact of our work.
This could be a symptom of an unsafe work environment. But it could also be that we're still thinking of just building things to ship.
A project mindset.
A product leaders we need to think about impact and value creation.
We need to show our work.
Also, we can not learn without measuring.
There's a lot of 'learning' especially from the 'failure porn' people.
While that's true, what enables us to learn is by looking at the output of what we shipped.
We need to have a practice and discipline around measurement.
We need metrics to measure, not just a measurement practice.
However we decompose our teams, each team needs a metric or two that has a relationship to the business or outcome metrics like revenue.
Engagement with a feature is a common metrics but is an anti-pattern. This is also a symptom of feature teams. Others may call it a vanity metric.
This is where product leaders and data science leaders can help teams understand the relationships of metrics to value.
Engagement can be valuable should engagement, for example, be positively correlated with repeat purchase.
Over time, we may see smaller improvements in customer outcomes and metrics.
Conversion rates are flat.
North Star metrics ( another post sorry) are flat.
There are, generically, two ways to view this: either from the supply side, or the demand side.
For a particular job, and a job step, is the customer's needs being met? Is there no longer a struggling moment for them?
What evidence do we have to support this - needs to come from the customer?
If so, we should decrease investment on this.
From a supply side, are our algorithms stale?
Is our product listing page, good enough?
May be we should focus elsewhere.
This is commonly known as horizon planning. Is our product mature? What does sustaining mode look like? Where do we move those team members?
May be we need a new AI solution to 10x. Should we incubate a new solution that would retire this capability then?
We tend to think about four different horizons:
- Incubating new ideas
- Investing in existing capabilities
- Sustaining investment - no change from last year for example
- Sunsetting. this will be retired this year.
We need a cycle, a regular cadence to review progress, impediments, and risks to our broader business and product outcomes.
It's only normal for this cycle to align with the business calendar, think quarterly.
We're not fans of status meetings, so this quarterly review should be thought of as a 'working meeting' not the PM providing a status update.
At the product team level, there should be a summary of OKR progress and metrics, what was shipped. This content should be a pre-read.
The working meeting leaders should seek to understand impediments and risks to the broader strategy and goals.
Leaders should inquire what they can do to help derisk these things as the PM would have tried to derisk at their level already.
The PM should also tell the story about where they are going next and what is needed to get there. A mini Product Strategy meeting - more on this in another post.
From a leader perspective, after working with the product teams, what parts of the system need to be changed or updated?
Are there external stakeholder who need to be brought into these sessions?
Are our annual business outcomes at-risk? Do we need to consider changing team's missions or refocusing them?
These are no doubt opportunities for managers to coach their PMs.
This is cohesive in that all the pieces are interrelated and work together. Without one of these pieces, the puzzle isn't complete and value creation wouldn't likely happen.
The resulting Product Op Model would be anchored back to the project model.