Death to the Roadmap

 An obsession with the creation and maintenance of a product roadmap is one of the best ways to stop focusing on your customer. It is a meaningless exercise that adds little or no value to a product organisation.



It’s the purpose not the Destination



Years ago, when I was in my late teens, my friend and I embarked on a journey around Europe. We were hungry to learn about all the funky countries on our doorstep and had little of no knowledge of any of them. Our passion and mission was to have fun exploring.


We used a ticket called ‘Inter-rail’, which for £100, gave us unlimited travel by train all around Europe for 1 month. So off we went. Once we had arrived at a destination and had enjoyed it, we then decided where to go next. Where we went next depended upon what kind of weather we wanted, how cultured we felt, how tired we were (you could sleep on an overnight journey and not need to pay for a hotel) and what time the next train was.  Depending upon those parameters we would write the destination into our ticket and board the train. The result, a deeply enjoyable journey that rewarded us with experiences for a lifetime. 


We reacted on a day-by-day basis and kept true to our original mission to explore, learn and have fun.  If we had planned every step day by day beforehand we would not have enjoyed or learned a fraction of what we did. We would have been anxious to keep on mission especially if unexpected delays happened (i.e. train was late). Even getting ourselves to railway stations at the right time would have obsessed us, it would have changed our dynamic. In short we would quickly have lost sight of why we were travelling at all.


I think this is analogous of what a lot of businesses do when they religiously build a product roadmap and try to stick to it (or at least pretend to).



What’s wrong with a Roadmap anyway


The problem with a product roadmap is usually due to the time it takes to develop features and the time it takes to sell them. I think most reasonable sized businesses would look to make maybe two major releases per year. However, the sales cycles will expect to close many more deals each year.


I do not think it is uncommon for development teams to be able to have a feature list, which could take over three years to develop. The result is that some features seem to be ‘always’ in the plan but never materialize into real product. This creates a cynicism throughout the business and as a result we get silos by default. What then happens is that the product manager (or whoever has this mantle) will manipulate the roadmap with justifications about why things are going to move out. They will waste valuable time producing artifacts that no one really reads and have no actual value to the business.

In any case, it is impossible for a development or marketing team to look into the void of time and space and really accurately determine what features are the one the business will need most. The further out the release goes then the quality of the business value tends to diminish.  So why do we have them and is there a better way?

 The traditional reasons for having roadmaps is to allow the sales and marketing teams to build sales artifacts and customer to plan upgrades. However, in reality the only assets that are really important to the sales and marketing teams are the ones that generate leads and sales. There will be a pile of others which no one really, really cares about (honest!). If the customer does contract a specific feature (or bug fix) that they must have then it is a contracted delivery and you will have to deliver it in any case. That I think is the point. The only features that need to be developed are the one that customers need in the short term, really, really need.

I know a lot of you are throwing your hand up in the air in horror. ‘A detailed roadmap is essential for any business to achieve its strategic goals’ you are saying. Now, I’m really a great believer of having a good strategy with detailed delivery objectives. However, I think what is more important than that is to keep an eye on your purpose.

Your strategic goals can and will change, but your purpose for being should not. You need to sit down and plan what you want to do, but remain flexible in execution. In world war 2, General Dwight Eisenhower was famous for saying “Plans are nothing; planning is everything”. I think everyone will agree that his purpose in WW2 was very clear but he gave himself flexibility in execution. 

Also, if you consider how many clever people have created great strategies but have failed to deliver them, you should get the point. The point is that most strategic goals are static and don’t pay enough attention to the customer or the competitor.

Now I hear you say, ‘but our idea is so great it will change things’. It’s been my observation that very few companies have done this, with the notable exceptions of an Apple, Starbucks etc. These companies generally have huge resources, your company probably does not. But you can innovate like crazy and produce cool stuff that customers need. Dump the old product roadmap and re-engage with your customer.


What Next


So, why not change your organisation to one that is known to be responsive to customer requirements and your whole business is aligned to delivering these functions. There is not a roadblock from the development team saying it’s not on the roadmap therefore we can’t develop it. There is not an overly long set of fictitious marketing messages that are never actually produced. There is not a roadblock to sales in prioritising functions that will make the difference in winning a valuable piece of business.

I know that a lot of organisations will flex in any case to try and win new business (they have too). What I am suggesting here is that we move away from the traditional roadmap approach and admit and embrace that there is a better way.

There can still be a dusty old list of features that parade as a roadmap. However, it should be though of more of a menu of possible features rather than the ten commandments of your product business. The whole business moves into a more aligned mode whereby the focus returns squarely to the customer. This is done by regular communication and agreement across the functions of the business about what is coming next and why.

If the business works in this mode then it will spend less time producing overly complex gantt charts and blaming each other. It will also be a much more dynamic and fun place to work. So, what is needed is for the executive to lead the way and remind the organisation of what its purpose. No matter what your organisation does, it will have a customer, remember to put the customer first.




Having a good software architecture is really important if you want to make money. This article tries to simplify the technology into a very short, non technical article that will help non technical business leaders understand what ‘software architecture’ means’ and why it is important to the bottom line.

I was asked by a business recently what the term software architecture really meant. The company had heard a lot about it but did not understand what it was. So I gave them an ‘architecture for dummies’ kind of response and they said they thought it helped them. So, here is the anecdotal , trying not to be technical, response to the question: what is software architecture ?

Firstly, software architecture is as important to software solutions as traditional architecture is for buildings. If you don’t architect a building correctly it will look horrible, be hard to build and may very well end up falling down. Software architecture is the same. I thought I’d explain it by walking through one classic software architecture: a layered architecture.

Programs are generally created by writing functions, i.e. “Get Customer”, “Calculate Interest” etc. The idea behind a layered architecture is you separate these functions into layers and mandate that each layer is responsible for one (and only one) major part of the overall program.

The diagram to the side is a classic layered architecture, this one has 5 main sections:

  • User interface layer only presents information to user and accepts input (generally, these are web browser or mobile app based interfaces).
  • Application, is the main program, i.e. “Run mortgage process”.
  • Business objects are high level supporting functions, i.e. “Get customer mortgage history”. These may get re-used in multiple points in an application layer.
  • Logical Data is supporting functions i.e. “Get customer addresses”, this will operate correctly no matter where data is physically stored.
  • Physical is the low level stuff i.e. “Get customer address from an Oracle database”, things like SQL are normally in this layer.

The communications between the layers is usually carried out behind well defined application programming interfaces (API’s). An API is actually quite simple, is simply defines what inputs a function needs to do it’s job and what the outputs are. For example, ‘Get Customer’ may require the customer ID number and will return their address and balance on account. This means I can change code behind the API without risking the creation of unforeseen errors to all the other parts of the program that use the API.

A layered architecture mandates that you can only call into the layer below. So the UI layer could not make direct oracle calls to the physical layer but would have to go through the application layers.

“So what”, I hear you cry! Well, let’s say you were using an Oracle database but then decided it was too expensive and you wanted to move to MySQL. Well, the only layer you would have to reprogram would be the physical layer. This will reduce risk and cost. If you had not done this your developers would have to modify many layers which would increase cost and increase the chances of introducing a bug.

More importantly, as the API’s themselves may not change, you can radically change the internals of a function (sometimes called refactoring) with little risk of breaking other parts of the program stack. So you might, for example, completely change the rules for calculating a mortgage but the UI, which calls ‘Calculate mortgage’ API, might not need to change at all. This allows companies to develop more agile and maintainable code faster. It also means that new software engineers know where to look for the code that they want to change.

So, is this what most software developers do ?

The Bad News

In my experience, there have been lots of times where developers did not think enough about the architecture of their solution. They were so keen to get on with the programming that they omitted this stage. I think this is because they may have been taught to program and not engineer or sheer time pressure makes them hack up a quick solution.

In addition, the business idea behind the software is often run by non technical entrepreneur’s who just assume that best practice is being observed. Generally, if the development is not being overseen by an experienced architect, it’s not being done.

This creates real problems for the business as it is normal for the software to be changed multiple times as the business pivots. The result is a code base of ‘Spagetti code’ which is hard to maintain, is buggy and slow to respond to the market. Therefore, as a business owner, ensure you have someone architecting the solution before the programmers start hacking away.

I also reckon that it is one of the key areas you should investigate if you intend to acquire a business with custom built software. Find out how the solution was architected and who knows how to develop and debug it.

Maintenance costs and unhappy existing customers, may be the pig in a poke that you could well do without.

Mind your Language !

I was speaking to a friend the other day and they asked what is the best programming language. Of course the answer to that is, ‘it depends’, however if you are going to choose a language you should choose one that is popular. If you don’t do that, you mat find it difficult to find people who can program in that language. This is likely to make your whole venture more expensive and risky.

If you want to know the current trends, then the Tiobe Index is a good place to start :

As of September 2019 the most popular languages are:

LanguageTiobe Rating

Engineering Excuses

“Engineers like to solve problems. If there are no problems handily available, they will create their own problems.” — Scott Adams 

Here are my top three great engineers’ excuses and what to do about them.

  1. This new technology is cool – we should use it

Your development guys will sometimes get bored with what they are doing. They will chat to their pals, watch a TV programme or discover a new technology or trend on the Internet. Before you know it, they may convince themselves that the business will fail unless in embraces this cool new technology.

Now, they may even be right, the technology may be cool and give you great advantage. I would certainly entertain a culture that allows these discussions to germinate, however you do need to get the guys to convince you as a team that this is the right thing. So, get your engineer to present to you why this will ultimately benefit the customer and to highlight any pitfalls they envisage. Also, if it’s a new development language or technique, ask how many others are using this. If it is a few, then it might be expensive to find developers to maintain the solution later.

Be prepared to reward them if the idea is good, but let them know that the responsibility to ensure this does not damage the business lies with them.

  1. The last guy who wrote this got it all wrong

Now, they may say something like ‘we need to re-factor this code’ or ‘I would not have done it this way’. To dis-arm this statement you need to have more than one person involved in the decision. Your product manager and team leader need to agree that this code needs to be re-factored (if the effort level is high). It needs to be balanced with the other activities the team is engaged with, therefore you need to keep your team up to date with what you are trying to achieve.  Sometimes, if it’s not broken you should not try and fix it!

  1. I think I can improve this by adding these neat features

Engineers are perfectionists. They will keep engineering until the cows come home. Don’t let them! Unless there is a clear differentiating function for the customer you should not build it. Period! I have seen many occasions where an engineering approach has developed useless functionality that is not only not used but complicates the system on behalf of the customer.

Again, to keep control over your team remember to update them regularly about what the company is trying to achieve and how well it is doing in it’s objectives. Encourage a less is more attitude and ask your team to balance customer benefits against build cost as a matter of course.

Stop !

I’m really a big fan of ‘Go, go, go !’. I believe that it’s better to get into action, with risk, as soon as possible. In my view, it is better to fix things on the move rather than get into ‘Paralysis Analysis’.

However, at this point, the point you have identified the product you are going to build, you should stop. This is not a full stop. It is though, one of the most important phases you go through when developing a product. That is to identify what your ‘company’ stands for. This means, you will identify the purpose of your business, your core values and beliefs and your medium term mission. I know this sounds a bit management mumbo-jumbo, but let me explain why this is really essential.

To understand why this is important it is useful to re-visit why you are creating a product in the first place. In general, providing a service to your customer will be easier and will be less expensive in the short term than a full product build. We know, the market has many systems integration and services companies that can deliver customer projects very well. In fact, most of our industry is just that.

So the reason why you are building a product is really to help you differentiate from these SI companies and allow you to compete and play in their geographies. Let me explain further. This first time I reached that conclusion was when was working for a business, which integrated accountancy packages on an open system platform in Scotland. For those of you who don’t know, Scotland is a small country both physically and economically. Very quickly, we reached a size where our expenses on a project could mean the difference between winning a project or losing it. For example, if I competed in a geography that was 200 miles from my office then I would have to pay for transport and accommodation. The local guy, who probably had similar day rates to myself, would be cheaper in terms of expenses and would argue that their more localized support was a great advantage. Therefore to compete with these companies you need to have something that the local provider does not have. One great way to do this, is to encapsulate your ideas into a product.

OK, your building a product to help you win more business in geographies you may not have been able to reach in the past. However, being able to explain why your product is fantastic is not enough you will have to convince customers, partners and new hires why they should work with you. Remember, if the market desires your product, it will create a ‘market’ and as such you should expect competitors. So your differential here will be your company.

More importantly than attracting more customers you need to have a clear identity to attract good talent. Good people will often sacrifice salary to work in a business they believe in. They will generally stay longer if they agree with your companies principles. They will certainly be happier if they are allowed to engage in the conversations regarding the direction of the business. Understanding where you start from and what your principles are, become very powerful drivers of success.

A geat book, that really helped me move my business to the next stage, is “Beyond Entrepreneurship” by Collins and Lazier. In this book the guys describe (much better than I ever could) the importance of core values, purpose and mission. To me, this is like dynamite, if you embrace this and engage, your team your chances of success will be 10X. If you do follow the guidlines in the book you will (in my view) attract the best talent, build the best product and feel more fulfilled. In future articles I will discuss in more detail how to workshop your purpose, mission and core values. In the meantime, take a peek at the book !

Value Pricing

“What is a cynic? A man who knows the price of everything and the value of nothing.”

  Oscar Wilde 


How do software companies determine the price of their products, and when should they do it ? This article describes some of the ways companies price products  but argues that value based pricing  may be the superior approach.


So, how do you put a price your new software product.

Free & Fremium: This is where you give away the software for free and make money out of related services, such as maintenance, training, advertising and the like.  This model works if you are good at holding your breath and probably excellent in marketing.

Pick a number: I suspect a lot of companies employ this model. I quite like the story of  Hewlett Packards first product, an oscilloscope that they priced at $54.40. The price was chosen because it reminded them of an 1844 slogan used to establish the northern border of the United States – “54” 40’ or Fight!.  Not necessarily a great strategy, but it did work for them.

Competitor based: What do the competition charge.  Be careful here as buyers sometimes associate the cheapest solution as the one with the lowest value. If you do price against a competitor you should try and find out why they selected their price and what the links to value are. Again, this strategy probably needs a good marketing strategy to support it.

Cost Based Pricing:  In this strategy you try and associate your costs of production with the cost of selling.To a certain extent all business will have to do this to keep running (i.e. you business plan needs an associated revenue stream). However, remember your internal costs have little direct relevance to the value to the customer.

Value Based Pricing

This article is really about value based pricing and why you should consider this approach before you start to develop you product.

Why do people buy products in the first place?

I like the article by Belle Beth Cooper Why people don’t buy products – they buy a better version of themselves. The article is based on consumers but I think the message works just as well in a B2B context. It’s a message we all know, people buy benefits and not features. However, most companies seem to drift into talking about features all the time. I think this happens very early on in the development process. This results in a disconnect from the customer on day 1 and probably investment in the wrong features.  So how can value based pricing help?

I believe that before product features are implemented or new products are invented we should all spend some time asking how this will make our customers lives better. One of the ways of doing that is to try and work out what ROI will be to them on your new product.

How do you do it ?

Simple ! You work out how much money your customer will save using your product before you build the product.

Ok, Ok, this is not easy but it is a great way to get your team to imagine how your product will benefit the customer on day one.  Also, understand that whilst the eventual outcome is to get a great price, it is ‘the journey’ that will make you product more relevant just by trying.

We do this by borrowing some of the techniques that the sales industry uses in solution selling and insight selling.  Simply put, these methods try to discover the real problems that a customer has now or latent ones that are soon to emerge in the future. They then try to quantify these and based on the price of the proposed solution will demonstrate why the ROI is compelling.  The problems are often referred to as ‘Pains’ and if you can evaluate frequency and quantum these can be mapped.

Mapping out the Pain

Let us work through an example. (Note, that there is a free diagnostic tool in the downloads section , it’s completely free and incredibly useful).

To calculate the pain of a particular customer I think it is useful to have someone in mind, i.e. not just a segment. Once you have someone in mind and have identified a pain, you will be trying to work out the following:

  1. How often does this pain happen?
  2. What is the probability of it happening ?
  3. How much does it cost the company when it happens?
  4. How much do we envisage we can reduce it happening?
  5. What additional value can we add to the events?
  6. How important is this event to the customer (note that high value events are not necessarily the most important, i.e. it might be a pain associated with a mandatory regulation).

I would suggest that for a new product of feature you should try and identify between 1 and 10 pains that you product can have a positive effect on.

Once you have done this you will be in a position to calculate the approximate value of the pain and therefore align the price of your product to that . You can also map them out (as in the screenshot above, please download the diagnostic tool for more details).  This will also give you some broad brush ROI statements that you can use in the sales process.

This exercise will be a combination of leaps of faith plus refinement. So don’t spend too long trying to be completely accurate with your estimations in the first instance. These can and should be refined. However, what it does do is force the development team closer to the customer. It will also serve as a document to remind you what you thought you were building in the first place. I think that one of the main areas where product companies go wrong is when the R&D team become disconnected from the customer. This technique will help reduce that happening.

What next ?

You can go with the number you have just calculated. You will already have benefited from the process of validating your thoughts against customer gains. However, you can go even further.

If you can get access to your target customer or a good proxy, you can try and validate your findings against them. This can be used as great relationship building tool as you will not be selling them anything at this point. Rather, you are in the position of asking them, as someone who has an opinion you value, to comment upon a new product your are trying to build. If they give you more accurate models to refine your data, it will become a winning situation. At a later date you may be able to go back to your target and play them back their own savings and therefore generating a potential lead.




Ideation is a horrible word, but it is a real word. It is the process of generating and developing new ideas.

This article is about some methods, which you might find useful when trying to come up with a killer product idea that sticks!

How do you get Ideas?
There is a lot of talk about sudden inspiration moments and certainly everyone remembers Newton’s apple and Darwin’s thunderbolt moment on the theory of evolution. As it happens, it now looks like both Newtons’ and Darwins’ ideas evolved over some considerable time.

This is backed up by discovery of early notes of Darwin himself (he was an avid note taker) on the theory of evolution, before his alleged eureka moment. Also, the fact that Newton’s ideas over gravity started in 1666 but Principia was not published until 1686 and even that was subject to a plagiarism dispute with Robert Hooke.

However, there is no denying that Fleming sparked an idea for Penicillin in 1928, due to a mistake in storing petri dishes. In is also undeniable that the Curies developed the idea of radioactivity based upon the earlier discover (also by mistake) by Becquerel of the properties of Uranium.

The point is that most ideas are probably the progress of a slow hunch, at least in the opinion of Steve Johnson. Steve has a fantastic video on “Ted talks” in which he explores neural networks and coffee shops of all things. This talk is about the fact that ideas are in fact neural networks that are formed in the brain. That is, before the idea came along these networks did not exist. So the art of thinking can create (or at least) re-arrange matter. If this happens naturally what are the conditions that will make it happen more often and how do you re-arrange you cells in the right order.

My question is: ‘Is it possible to create an environment that encourages these early innovation sparks and fans the progress of them into ideas with an implementation plan?’

I believe this is indeed possible.

What is the best environment for creating Ideas?

It is well documented that both Nietzsche and Einstein both suggested that to solve certain problems it was necessary to think like a child. This has certain resonance with the theory of lateral thinking by Edward De Bono. Both these suggest that you will have a better chance of having new and better ideas if you can remove the shackles of your own constraints.

The problem with most adults is they already have a way of thinking how things work and what will and wont work. As a result a lot of ideas don’t get off the ground. They know the idea will fail before they even finishing the development of the idea. Children do not think like this and by trying to think like a child, without constraints, you may well come up with many new and exciting ideas.

Research also seems to suggest that most ideas are actually formed in groups where active discussions are going on. Think about the way good brainstorming session’s work. The perspective of many people, can often add value to an original unformed idea. Indeed, it may be postulated that two people might each have half the idea and through discussion can come up with a better fully rounded one. So if group discussion is the good way to create great ideas why do these discussions often fail?

To answer this it is worth re-visiting the transactional analysis theories postulated by Eric Berne in 1964 in his book ‘The games people play’. In summary, he states you can think of human behavior in three distinct ego states: adult, parent and child. It is still a great book, but I’m not going to get into detail about it here. In short, Eric says, that the transactions played out between ego states have a huge impact on the outcome. If we believe the creative parts of people seem to reside more in the child state, then we need to be careful not to stifle those parts. However, unless it is treated properly an adult to child discussion or a parent to child discussion may end up killing the idea dead!

Think about children with cardboard boxes; to the kids they are castles and racecars but to the parent they are a mess. So, the parent reminding the child the racecar is in fact cardboard junk will end the dream and kill the idea. So when group of people get together they need to be careful to protect he child state of the creative discussion.

But, it is often the case that participants of meetings might interject why an idea may fail due to their own experience. This might happen before the idea and its tangents have been fully explored and the avenues of the idea will be closed down at this point. If we can try and direct the conversations away from these roadblocks and diversions we will allow more ideas to flourish.

So, attempting to think like children in an ego managed environment may well prove more fertile in the long run.

Another approach that athletes often take is utilizing positive mental attitudes and in particular creative visualization. This visualization technique sees us imagining what victory would look like, feel like, smell like etc. With that image in mind you then work back to how you got there. This is useful, as by working backwards must have already removed the roadblock to thinking about why it ‘cant’ happens. Instead, your frame of mind is trying to find out what you did to remove the roadblock rather than stopping and staring at it.

Developing the Idea
When you are trying to come up with a new idea it is really important not to try and evaluate them too quickly. Generating the ideas is the important thing. So think of idea generation as a two-phase process:

Create the ideas
Develop and edit the ideas.
The objective of the creative session is to create as many ideas as possible. These will be written down and analyzed at a later date. To create the most conducive environment for idea creation you want to tap into your child state. So, here are a few things you can do:

Set the ground rules. There is no such thing as a bad idea.
Try to set the mental state of the participants. Folks will come to meetings with their own pressures and prejudices and probably a strong feeling for how things should get done. Try to break these down by some lateral thinking exercises and puzzles. (A selection of these are in the downloads area).
Try to get a cheery room with colors. Provide colour notepads, crayons, sponge balls etc. Things that remind us of our child state.
Provide a big jar of sweeties. Can you find old classics that might remind the audience of their childhood, for me it’s cola cubes. It is also worth noting that according to Professor Robin Kanarek, ‘Glucose is the best fuel for the brain’.
Tease yourself, ask questions like: ‘How would I solve this problem with the technology available in 100 years time ?’
At the end of the session, write all the ideas down. Remember that long hunch.
Have fun, its what kids do best.
After the fun section you need to re-group and analyses the ideas to see how they can be commercialized.

Develop and edit the Ideas

Make sure this happens in a different session from the creative one. In fact on a different day if possible, ‘do away with childish things’. The adult approach will be needed to calculate if the idea is worth developing.

At this stage I think you should try and become the persona of a customer you are going to target with your idea. Focus on the benefits to the customer and map out what the likely ROI for the customer might be. A good way to do this is to try and price your product and come up with a customer pain map. (Please see my article on value pricing for more information on this.)
If the idea does not commercially work try some of the others. If none of them work plan another creative session on how you might make one of the ideas work. If you can invite new people to this then that will give some better perspectives.
Once you have an idea that works and a potential ROI paper you should try and get feedback from a potential prospect. Do not try and ‘sell’ them the idea but ask them for their opinion, which you respect. If you have an ROI case you might get better data as they may very well tell you that your numbers are wrong. If they like the idea, then you have a potential prospect for the future.
Build a prototype. Without one you might find that peoples ideas on what they thought the idea was will actually change.