If you are like most product owners, your day goes a bit like this.
You arrive at 9, with the best intentions of making a real difference to the product, to the lives of the customers and to the business.
After settling in, switching on the laptop and having a quick scan through the inbox, coffee is most definitely required.
An ‘urgent’ issue has cropped up overnight from one of the important customers, and it has managed to get the attention of the CEO so it’s something that has to be looked at.
That will have to wait, there are only 10 minutes until the daily standup.
The morning progresses. After the daily standup with the development team, there are the usual ad-hoc conversations with different developers following on from issues or points raised in the standup.
It seems like most of the morning has gone already, and that urgent issue still needs to be looked at.
A quick scan of the email from the customer reveals very little. You email your support team to provide more information.
“It doesn’t work” simply isn’t going to cut it, and isn’t something that can be given to the development team to fix.
Unfortunately, it’s left to you to try and extract this information.
Next, into a status update meeting with the various ‘stakeholders’ in the business, including the CEO.
They need a status update on the work that’s currently in progress, plus the urgent issue. Don’t they understand they can’t have both?
You get the picture.
The day progresses in a similar way. It’s a mix of answering queries from developers, updating management on the status of work, and trying to find time to look at what the business needs in the future.
None of this feels like the way product ownership should.
It’s much more like project management in disguise without any power to actually be in control of that delivery yourself.
You end up trying to be seen to support the development team, to let them do their thing, trying to keep management happy and trying to let them know when features will ship as the same time as carefully balancing urgent issues that seem to arise on a daily basis.
You feel stressed just trying to get the development team to work on what is needed whilst still being seen to be agile so they aren’t pissed off with you trying to tell them how to work
You feel completely powerless to deliver what everyone wants let alone what customers actually need.
It’s impossible to keep everyone happy. It’s all about damage control.
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