The first, and probably most important thing to stress here is, you are building
product roadmaps. The second thing to say is, do NOT build out product roadmaps at an executive level. All too often, product gets mixed in with strategy, as in, the executive think they are putting together strategy but rather they
are talking products. To be frank, they are very different things and it’s a trap you must always avoid.
The role of the executive
The role of the executive team here, and board for that matter, is to dictate strategy. This doesn’t need to get overly complex, and while setting that top level strategy, do not think about product. No, strategy is all about 'where you want to play' and
'strategic objectives'. The executive and the board need to get this right, first and foremost.
I personally, try to push strategy discussions to start with a 'generic competitive strategy'. The best example to follow I find is Porters Generic Competitive Strategies, which focus on three main areas,
- Differentiation (which can also be seen as 'unique')
- Cost leadership (beating the competition on price)
- Focus (or providing niche products)
I am a big fan of visualisation, so Porter’s triangle below really helps bring these strategies into focus.
The first thing to point out is, that to be successful, you need to be 'playing' on the edges of the triangle, if you wonder into the middle then you’re not likely to win customers away from the competition. You can 'wander' towards the corners, so you can
provide a rather unique product offering that also can be delivered at price points that make incumbent approaches look significantly undesirable. Likewise, you could provide products that are unique and yet highly focussed on a niche part of the market. The
key to this triangle is understanding where you want your products to strategically land in the marketplace.
Once this has been achieved, it’s time to feed into a product steering committee.
Product steering
The link between executive and product steering is key to the overall success of the company, it’s that important. If you are unable to join product with strategy, then your organisation is going to struggle, product direction will constantly 'flip flop'
and feel highly re-active as opposed to pro-active. As for building great product roadmaps, well that will be a constant struggle.
Product steering has to bring together the right people, people who 100% buy-in to the strategic vision, people who understand the market, people who can ascertain product fit, people who are innovative thinkers and people who can align engineering domains
to product vision. We have to remember too that, smaller sub-set products, that have already been built, will have an organic roadmap already. The evolution and development of those products are key to their long-term success, so those product roadmaps must
be fed back into this group.
Product steering therefore is about defining products that land on our Porter's Strategic Triangle in the right places.
Product steering cannot be just all about setting product and filtering it down to engineering domains and teams, no, its also about engineering teams and those with relationships with customers, filtering back up to product steering. In many ways, product
steering is the melting pot.
Once you start to form a sense of what products should look like, to meet strategic objectives, then you can also start to look at what needs to happen across the organisation to get there. Now that may mean bringing together very different parts of the
organisation, in our agile engineering culture, that’s collaboration between domains potentially, keeping in mind that domain owners may already have their own agenda of features that they feel must get onto the roadmap asap. Alignment here, within this steering
group is crucial. You must have a “team” mentality, or you will find you cannot get product to align with your strategy.
Once you have your products meeting your strategic objectives, it’s all about roadmap iteration.
Visualisation and iteration
Once you know the top-level products and sub products that you want to build to meet strategic objectives, you must recognise that they are products and not projects. I know this is a theme I have mentioned time and time again in this series, but you really
do have to think that way. If all the “sub products' need teams, then you can start to see how many teams and resources you require to meet your strategic objectives. You can also allow products to move iteratively forward, focussing initially on your
minimum viable product only and allowing the market and your innovative thinkers to guide you iteratively after that.
Visualisation of products, capabilities, where they may fit in a roadmap is highly powerful. All my roadmaps are visual. Also, forget dates, rather look at the roadmap as a puzzle, identifying features, dependencies, key milestones and build the pieces
into a picture. Once that picture starts to form, you know you can start to follow a very agile approach to iteratively improving and enriching your product, taking on feedback from customers and your innovative thinkers.
If you have a desire for dates, markers in the ground, then you haven’t been reading this agile series. That being said, yes, sometimes dates are a must, but don’t fall into the trap of setting specific dates. Try to establish a benchmark of what might be
expected in a quarter at best, rather than a specific date. We want to keep iteratively delivering product, product updates and features, not set dates and targets and try to predict the future. As I say, speak of quarters or even better, 'semesters', splitting
your year into three. Remember your key principle, value delivery over
predictability of any dates.
Validating your roadmap
An organisation wide roadmap is not owned by one person, rather it should be a collective organic thing, bringing together many various product roadmaps, each constantly moving, each constantly changing, each constantly adding value back to the organisation.
Constant validation of your roadmaps is required, constantly involve teams, feedback from customers, innovative thinkers and look at each individual sub-product in detail. Where can you improve and add value to the customer, where can you improve and reduce
costs, where can you improve and make things safer. Feed up from engineering teams back to product steering, while at the same time, assess the bigger wider picture, look at the roadmap puzzle and ensure everything you are doing is meeting the strategic vision.
There will be many features that bubble up that take you away from the edges of your strategic triangle, assess them, validate them, don’t build them if they compromise strategically where you want to be playing.
Product steering really is the glue that brings executive, product owners and engineering teams together into a single melting pot. For me, product steering is the beating heart of your roadmaps and in many ways, your organisation. Get this right along with
your agile engineering culture – and you will thrive.
Thanks…
I think this post is a good place to end in terms of the agile series. In this post we have looked at the importance of alignment up and down the organisation in order to make sure we are all moving in the same direction, we have the same macro level goals
for the organisation and that we are able to make sure that all the moving parts, all the products that we create come together to form the organisation we all have in mind.
Great leadership, the ability to empower people, great communication and creating great alignment are all key areas of any successful agile culture. There are so many ways to implement agile engineering culture and you should not be 'wed' to any one approach.
Agile is about getting the way of working right, efficient, and effective with the people you have at the heart of it. I hope that this series has highlighted that agile is not about a specific practice, or specific processes, organisational structures, rather
agile is simply about people, principles, and focus…