Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 3 Next »

Timeline Roadmaps (Designed to Fail)

So this looks good?

Looks good today - your boss likes it. However, this actually sets teams and organisations up for failure. Why?

What is this showing? If you strip it back you have time and things to do, so you start adding the different features and in the short term it seems pretty simple and easy to use.

So you start adding your features…..

However, the more you add, the more you plan and the further out you go the harder it becomes to manage.

No matter what you do, everything you add to the roadmap always includes a time estimate and due date.

As a result, your roadmap is

  • A big pile of features

  • Loads of deadlines

All based on a set of assumptions

Assumptions

Using this type of roadmap means you are assuming the following

You know how long each feature will take

Perhaps this is easier in the short term as you have spoken to the team and lot’s of details have been discussed and you have some estimates but the further you go ahead in time, the less clarity you have.

Nothing else will come in

So no new ideas from customers, no market changes, no competitors release a feature you were going to release later and there is no need for iteration.

Everything will work once launched

So you have managed to build something in the time predicted, the next assumption is that what you built works in the exact way you expected, users accept it and there are no improvements to be made.

Features should actually exist!

By adding features to the timeline, you are assuming that these features should definitely exist are part of the strategy and should be built.

Nothing will change

Finally, your assuming.

What could go wrong?

So you added an item to the roadmap and it's been shown to important people who all now expect this to be completed around a certain time and you are assuming that when you start getting feedback on what you have built its what the user wanted.

So these made-up dates result in stressful “death marches” for teams who end up burnt out and quit trying to launch on time and the sales or marketing teams have these set expectations based on dates that you simply can’t meet.

What’s the opportunity cost, are you missing out on building something more relevant to the market or you users just because it was a feature already set on the roadmap put there 6 months ago.

Organisations

So this makes sense? So why do organisations struggle to adopt any of this?

So for product managers, can they drop their timeline-based roadmap and if not why not or what can be done?

Shareholders

Companies have to increase the money given to their shareholders and as a result, CEOs are pushed into showing a steady increase in growth or cost savings. As long as its going up, even if a small amount is better than nothing so, predictability is king!

How to get more predictability - well break up into smaller chunks but then your organisation ends up into silos, e.g. marketing, sales, R&D.

At this point, you might be wondering what any of this has to do with vanity metrics, well with each silo being measured and with pressure to show growth for shareholders and investors, what do you start to measure?


Vanity Metrics

Silos start leading in the dangerous world of vanity metrics, so each silo is competing with each other are under pressure to maximiser their metrics rather than collaborating for the good of the business.

Some areas of the business will be able to reach whatever their metrics are, but what are the knock-on effects, e.g. reduce the costs but the number of complaints increases

Profit vs Cost Centre

Each silo within the organisation is seen as a

Profit Centre - this is areas of the business where if they put investment into the silo, they should make some money e.g. an increase in revenue.

Cost Centre - this is areas of the business that need to exist but money spent here is going to be less than you get back.

Product development teams are found in cost centres

So the main issue for executives here is control, to reduce costs to have control so this leads to the way measurements are at the moment.

For Sales, the more money you put in here the more you are likely to get out and it can easily be measured by revenue, marketing can be measured with the return in investment and as result of these habits and cultures across silos, product teams end up getting measured in very similar ways.

The result is that product teams are measured using this old pattern, so measuring points and time e.g. velocity.

What is this actually measuring and what does it mean teams will do? This setup is optimised for trying to build as many features as fast as possible.

As a result, many teams suffer from burnout and you end up building an unstable product (tech debt)

Product Teams doing this are focused on output rather than outcome

However, measuring a teams velocity can give the product development silo costs which can be measured and give an easy way to tie the cost of development with what has been delivered and provide that predictability that organisations and CEOs love.

So it seems easy! If we want to deliver all these features then we just need to get a load of developers?

So we get a load of developers and we have all these features so we deliver a great product?

Oh an the team is burnt out, quits and there is a load of tech debt


What can be done!

The most common resistant to change is

  • My boss expects it - he/she won't change and has to have it this way!

  • Sales are relying on me - feature sold before it's even been built.

So sales and executives are passing the buck!

They are asking product development teams, mainly product managers to provide predictions when working with unpredictable and complex environments.

Product managers are given the impossible task of playing project managers on initiatives that are never given enough time for planning and trying to protect developers from having to try come up with super detailed waterfall type estimations and when things go wrong, the product teams get blamed.

So why are…

  • Items being sold when not built?

  • Why are these all-encompassing projects being done at all?

  • Why are things being asked for without allowing time for proper estimates

How to cope!

Other silos like sales, the Director has a sales pipeline and she won’t guarantee her 10 salespeople will provide 10 million and a fixed date but she does use the pipeline and a percentage likelihood - these are estimates rather than promises of exactly how much and when. This works and is accepted with organisations.

Marketing - “Half your advertising dollars goes to waste” - marketing is an experimentation engine and great marketing organisations are able to change their plans based on current events.

So in different areas of the organisation, they have found a way to get around uncertainty, what can the product teams do.

Consistent Growth

Why is it a trap? Everything looks good, we have smooth constant growth. Companies loose grip on the bigger picture, they become obsessed with the quarter on quarter, year on year growth and reducing costs of costs centres and maximising profits from the profit centre.

So by optimising for the short term, they leave behind the option to be flexible and solve new problems in the future. They often find themselves with other companies nipping at their heels e.g. startups vs 100s-year-old companies in banking.

The reality is every product gets to a point of maturity and the companies start plateauing and for the companies at the top of the plateau are only growing by a fraction of a percentage e.g. Walmart, Ford, Coca-Cola etc. Their base numbers

  • No labels