product
op-model
transformation
Project to Product, False Dichotomy
When a company is starting their transformation initiative, consultants often will talk about 'project to product'.
Everyone's excited about all the changes and magic that is about to happen.
We're about to 'product all the things.' Project to Product.
Everything's a product, right. Right?
Wrong. This is a limited way to view a transformation, but it sounds good.
Here are a few reasons:
- Not everything is a product, you still need projects
- If everything is a product, you aren't being intellectually honest about 'value'
- You don't understand or are underestimating the product skills you need to develop or hire.
Not everything is a product, you still need projects
A product is a solution to customers problem that they hire to help them achieve an outcome.
Improving a product should result in improvements your business.
As a consequence, we invest continually in these assets, we expect a return.
A project is something that may or may not be part of a product/capability, but it's not something a customer specifically hires your company for.
Projects are typically things that need to get done on a given timeline.
What might some examples of projects look like? Implementing a CRM, updating a database, and deploying to a cloud environment are just a few.
There may be benefits associated with this such as more scalability or increased performance.
These aren't what the customer's buying to help them solve for their Job-to-be-Done.
Yes, a customer assumes your product will be available and performant. If not, they'll likely fire your solution and select one from your competitor.
If everything is a product, you aren't being intellectually honest about 'value'
A project is something we do, we try to minimize the cost and time involved. It doesn't add 'value'. There's a lot of product theater around what is 'valuable'.
This really is a core attribute to the product model, you can not skimp on being clear about what 'value' means.
You can measure value creation in two ways - only two ways - by 1) increasing revenues, and 2) decreasing costs.
Improving productivity, a common value prop, does not by itself create value. It has to either decrease costs, or increase revenues.
This is why CFOs do not buy 'improving productivity', nor should product leaders and managers.
Instead, we need to dig deeper to understand how this capability/product creates value for the customer and after, how do we measure that?
In some cases, we may not know, we may take an educated guess or create a hypothesis about what this value lever might be.
Progress over perfection. But we must dedicate or empower a PM to determine this and set a timeline for when we revisit this.
Also, while this happens, a good practice would be to maintain or decrease the size of this team.
This direction may be deemed harsh or unfair, but there are a couple of reasons we want to take this approach:
- Since we don't understand value creation, and a core component of the Product Model is optimizing value creation. We move critical talent to other teams where value is known.
- If we were to keep the engineers and continue building, we'd potentially improve the product/capability without a corresponding return. This is a huge source of waste.
You don't understand or underestimate the product skills you need to develop or hire.
Having highly skilled Product Managers and teams represent a serious commitment and investment into improved value creation.
Despite what the consultants peddling Agile to you say, it takes more than just having your PM candidates take the CSPO/PSPO certification and take a storymapping class.
Much more.
There are critical strategy and discovery skills you need to develop or acquire if your focus is on value creation.
If you don't, how certain of success are you? How certain would you like to be?
What should you do?
There's a lot you can do:
- Start off by ensuring you have a product leader who has the required chops. This product leader is focused on value creation. They aren't a builder first and foremost.
- Recognize that a blank 'Project to Product' talking point is limited and nuanced. There is some truth, but there are certain pitfalls that will put your transformation at signification risk.
- Acknowledge you may get certain things wrong and that you'll iterate on them. Create transparency on these things by publishing a decision log. Incorporate the review of critical past decisions into your Operating Review cadence.