From Projects to Products
Talking about product culture can sound very theoretical, but it impacts everyone every day. To try and bring these principles to life, here is an example of a very common before and after.
In the old models, it is very common that everything is about building projects by certain dates.
It’s understandable where this comes from, as the IT department is constantly asked for specific features and projects delivered as fast as possible.
The problem is that this ignores the realities of technology-powered products.
Projects are typically large, slow and expensive attempts at delivering some output by a specific date. We have to decide how big the team needs to be, and guess how much time it will take, and then we need to try to get funding for the effort, and invariably we learn that there is more work required than you first expected, so there’s a real crunch to finish.
Most efforts lose all hope of providing real value, and just try to get something shipped. Then as soon as they do finally ship, it’s not like they can iterate to improve the product. Instead, the people usually scatter off to their next assignments; nobody owning the outcome, and any important learnings from the effort likely lost.
There are so many things wrong with this.
First, it normally takes several iterations, based on learning from the prior iterations, until we achieve the necessary results, but we rarely get funding for more than the first attempt, and even if you do, it’s usually multiple quarters later.
Second, we need the people to feel real ownership of the technology and the outcomes, but with projects where people are assigned to an area just for the duration of the project, there is very little ownership, and there’s little incentive to worry about building something impactful.
Third, it’s all about delivering the features and projects that the stakeholders are asking for, rather than allowing our product team, especially the engineers, to look at what’s just now possible. The result is that any form of innovation is exceptionally rare with projects.
Fourth, because teams just build what they need to for that project, there’s no one to worry about the longer-term impact of this work, or improving the underlying technology, so tech debt rapidly accumulates.
Finally, who takes responsibility for driving to the necessary outcome? Any sense of ownership is usually dispersed among multiple stakeholders, and the most likely consequence is to blame the project team for doing such a poor job.
In contrast, with the product model, we focus on products and outcomes.
A product team focuses on business outcomes, like reducing churn rates, or improving growth, or whatever the relevant KPI’s are for your situation, and the product team is constantly working to monitor and improve those results. The capabilities they add are all intended to drive those results. They are obsessing over the outcome.
Partly this is about changing to durable product teams focused on business results, but partly this is a cultural change where a team is asked to be accountable to outcomes, and not just shipping features.
In the project model, the best you can really ask for is time-to-market. But in the product model, you can focus on the much more impactful time-to-money.
What is especially ironic is that you might think that a time-to-market project at least would get done faster than a time-to-money product team would achieve an outcome. But so often it is just the opposite.
While the project team has to staff up, learn the necessary technology, establish the necessary relationships, and understand the necessary context, a product team is already operational, and has likely done many similar projects and features already. So, in addition to being up to speed on the technology, they know much more about both the problem and solution space, they know the data, and they know how to work as a team to tackle a problem.
This is why far and away the most waste we see is in companies running in the old project model.
None of this is to say that time-to-market isn’t important. It is. And speed matters. And we do have solid techniques when a date we can count on is the priority.
That said, the heart of the matter is the question: What is more important for this effort? Hitting this date? Or accomplishing this outcome? I’d be the first to say that sometimes the date is the priority. But I also believe that this is the exception and not the rule.
It’s easy to see why so many companies may talk about the importance of outcomes over output, yet their culture and behaviors consistently prioritize predictability over results.
