You can’t move for people talking about the project to product journey lately. Getting organisations to start mapping out what their products are so they can build cross-functional teams around them. Projects are transitory and lose us all of the learning, we want long-lived squads! While these sentiments are all rock-solid, unfortunately, they’re missing the point. I’m going to be controversial and say that creating a product team simply isn’t good enough. What you actually need is outcome alignment.
The case for product teams
This is easily a pretty in-depth article in itself, so I’ll be brief. We’ve known for a while that projects are not a great way of managing IT projects. They are functionally divided which results in us trying to optimise for utilisation, this extends lead times and delays learning. They are centrally managed by a PMO, which disconnects teams from customers. Project teams are transitory, resulting in loss of learning and loss of ownership when the team is disbanded. They attempt to optimise for predictability through the creation of those wretched lies commonly known as GANTT charts. Safe to say, projects are not the way to execute in a complex environment.
So product teams to the rescue. We flip the IT organisation 90 degrees and create cross-functional teams aligned to products instead. This reduces administrative overhead, accelerates learning, and promotes ownership and improved quality through you-build-it-you-run-it. I’ve actually designed and run workshops to help organisations re-align to products. As with most things, I’ve mentally started migrating to a simpler solution. One based on principles.
The case against product alignment
The problem with product alignment is that we go through all of that work for something that could just go a little further and absolutely nail it. There are two main issues I have.
Products are transient
Products last less and less time in the market recently, you might be lucky with 2 or 3 years in horizon 1 if you saw success. Why align your IT organisation to something so changeable? What happens if we need to shelf it, do we re-org?
Products are not customers
And why go through all of that hassle of rotating your organisation only to cut just short of the customer. One of the main reasons we went through a damn digital transformation in the first place was to better react to customer needs.
The alternative – outcome alignment
Instead of stopping just short of the finish line, take that final step and connect your teams directly with customers.
When working through your outcomes, instead of dividing product lines, divide customer outcomes. Instead of building your tribe around an app, do it around a customer need. Customer needs resonate far more strongly with us as individuals and as teams, promoting purpose. Customers are less transitory than products, reducing the organisational overhead. We’re less afraid to pivot if we align to helping somebody solve their problem than if our reason for existence is the app.
I don’t think this is a big change, but something that I see having real value. Just changing that language can make a difference.
We don’t make apps, we help customers.
While customers can change, when we undergo a market segment pivot for instance, it is far less common. This is a problem I can live with.
Let me know what you think.
It’s nuanced, but you make valid points.
To most of my clients I’m talking about services (service design), with the idea that we are focused on creating better services for users. These services are enduring and we drive towards creating better outcomes from them.
An example would be “change my details”, this is a an almost universal service for any company. Better outcomes might be the ability to self serve for example.
I would still take a product team over traditional siloed IT teams based on function or skill. Taking teams further away from the point of contact with the user is not desirable, so even a product team is a good step.
I think service design has a lot of good stuff to teach the broader product community, they often seem more clearly aligned to a long-lived outcome. Whenever I say product or service, I believe that the other can be substituted without much effort, at least in my writings.
Your example is great. Although updating details is a common and long-lived activity, it can constrain those who aligned to it, resulting in a sub-optimal experience. As you point out, delivering self-service capability by aligning to the reason why we care about up to date details allows for innovation.
And 100% on your last point. Functional alignment simply doesn’t work for complex environments, and product alignment is a giant leap towards a better place.
Thanks for your comments, James!