Sharing is caring!

Imagine the scenario. It’s a Monday morning. You are walking into your CTO’s office for the weekly status updated meeting, and he asks the dreaded question:

“How’s the project looking”

Your heart sinks. You have to fall back to the usual response of my dev team are telling me it will be done this week. There are the usual good reasons why it wasn’t ready last week.

“Defects were found in testing. These had to be fixed otherwise we leave the customers with broken or partially working software…”

He cuts you off before you even finish. His eyes flinch.

He leans forward at his desk and in a raised tone says, “Again? That’s not good enough! What else?”

“There were edge cases we didn’t know about last week. There are some changes we need to make for it to be good enough.

Oh, and our tester was busy testing other features. Our ops guys needed time to deploy the changes so they…”

His hand comes up, “Just get out, fix this. Report back to me this afternoon.”

As you close the door behind you, you hear a shout from inside your CTO’s office…

“F*cking devs”

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

1: Planning

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.

2: Development

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.

3: Delivery

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?

4: Change

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.

5: Culture

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

Reserve My Seat

Leave a Reply

Your e-mail address will not be published. Required fields are marked *