Let’s face it, most product owners don’t truly ‘own’ a product, or area of a product.
Most of us are more product managers responsible for keeping the development team on track, trying to deliver what the execs in the business are asking for, according to their latest strategy or promises they have made to customers.
Every time a feature ships later than expected, or doesn’t quite do what a customer was promised by sales we get the blame.
It usually results in being called into the CTOs office and having complaints fired at you for the next half an hour.
“They are too many bugs”
“The team don’t hit their estimates”
“These features haven’t been properly planned”
When things go wrong, they blame the product owners.
We blame them for selling something that doesn’t exist yet, for making promises to customers that we can’t possibly keep. Not on top of the rest of the things they have promised to other customers.
When things go well though, when features do ship to those really important customers, it’s not us that get the credit.
Not at all.
In the weekly tech meeting, the CTO is more than happy to stand in front of the whole tech department and congratulate the developers on doing such a sterling job of getting those features out on time.
If only they knew the truth. Those features barely work.
They work for that important customer, but we all know there are going to be problems in the coming weeks that we have to address to actually finish the work.
And we all know who will get the blame for that.
Product ownership, management and software development does not have to feel this way.
Let’s face it, most product owners and technical leads don’t have a very well defined role, let alone training and support to help us work at the best possible level.
The modern agile world has left us with as many problems as it has solutions.
We have all worked with teams that have sprints, daily standups are doing Scrum, but not really.
Many development teams still see “the business” as interfering, as a group of managers that simply don’t understand software and slow down the work.
Most people in “the business” are frustrated by a lack of visibility and connection to the product and customer.
As product owners, we can improve this situation.
We can be part of a dynamic, highly engaged team that truly values the work they do, and works to support the organisation they work for.
In teams like this, work can seem to flow effortlessly. We know how to correct problems as they arise. We can see how our work impacts customers, impacts the business, serves to grow the business.
You don’t need to be a Facebook, a Google, or a Spotify to do this. It’s not difficult. It’s just not something that most people do or know how to do.
In this post, I want to talk about what I call The 5 Pillars of Product Development.
These are the 5 core areas that research has shown are critical to enabling teams to work at this level, to massively outperform other teams, their competitors, and to work in an environment that is genuinely rewarding.
Within each of these pillars of product development, there are a number of capabilities.
A capability is simply the power or ability to do something.
These are tools that all contribute towards getting to this state of effortless flow in product development.
The 5 pillars of product development
Planning is where customer and market needs are developed.
Good planning allows the successful formation, validation, and ongoing development of a successful business model.
Planning is much more than prioritisation and is where we should feel closest to the needs of our customers.
Planning also has to account for the unexpected.
After all, defects, change to requirements over time is never really unexpected.
The capabilities we can develop within the pillar of planning allow us to truly understand the value to our organisation that proposed features or strategic initiatives can provide.
Development is where the code gets created. This defines how the development team work on features, how that translates into code, and how their work comes together.
This is where most organisations typically focus. It’s understandable.
Developers are the bulk of an engineering team, so, therefore, they have a significant voice, and many methodologies are very developer-centric.
There are understandably then, many capabilities that fall within this particular pillar of product development.
This isn’t just about Jira, Git or any development tooling.
It’s much more than this and covers how non-functional requirements are managed, how the developers work together, how safety can be achieved even in software that is rapidly changing on a daily basis.
Delivery is where the code that has been created progresses to a point where real people are using the software, getting value from the features developed.
If development is where most people focus, then delivery comes a close second.
DevOps, and continuous delivery are very popular topics right now with many organisations trying to get onboard as the next evolution of their cloud journey.
Most organisations fail to fully appreciate that delivery is about much more than this.
It’s also about quality control, and it also has to consider what the concept of a release really means, and who actually benefits from different types of releases.
I’m a massive fan of DevOps, but time and time again, I have seen teams focus and invest far too much into this area far too early.
The various capabilities within the product development pillar of delivery need to be considered together and in the context of the other pillars.
After all, why spend months automating deployment to reduce the delivery time by one day if it takes 6 weeks to deliver a feature in the first place with no real means to judge the success of that delivery?
Change is the pillar that defines our ability to react to market need and remain responsive over time.
Developing strong capabilities within the product development pillar of change can secure our place as a market leader.
Organisations that demonstrate moderate success here are able to deal with change when it occurs, which feeds into the planning pillar.
Organisations that go above and beyond that level are able to anticipate change, even before customers realise it themselves.
In teams that excel in this area, every part of the way they work is carefully designed with the ability to pro-actively monitor their work as it is used by real customers, in real-time.
They look for failures of course but go beyond this to ensure they are notified if the assumptions made in product development about the way customers interact with the product prove to be incorrect, or cease to remain true over time.
First up, this isn’t about bean bags and table football. Yes, it’s about how the people in your team feel when they come to work, whether they dread or can’t wait to get into the office on a Monday morning, but it’s much, much more than that.
It’s about whether you work in a power-oriented, rule-oriented, or performance-oriented team and organisation.
It’s about whether the leadership within the organisation at every level is able to foster a culture that provides intellectual stimulation, motivation and drive to succeed at both an individual and team level.
It’s also about whether the level of challenge is right in the organisation, whether the environment provides the necessary triggers to allow that elusive feeling of high performance, of ‘being in the zone’.
It might sound like some of these are obvious, but in teams that truly understand these and can integrate these strategically, it makes a real difference.
We have found that by taking a proactive approach to the measurement and development of capabilities within these 5 core pillars, product development can be truly transformed.
Interested in learning more?
Join our webinar Understanding the 5 Pillars of Product Development where we break down these 5 pillars and look at how you can use these to transform the way your team work