Business Savvy Software

For a long time, we had a two dimensional roadmap – ie a list features and some release dates.  It was quite hard to communicate any dependencies and how projects were prioritised so there was a general feeling that we were just rolling out one feature after the other.

A roadmap is really only useful if you know your destination, otherwise its just a bunch of ordered features, so the first question to ask is:

What is the destination that this roadmap takes our company/product to?
Its quite likely that there will be some competing goals here – maybe its to open up new markets, or maybe its to innovate in your existing market. You may need to focus on one goal, or a few, but its important to first understand your goals so that you can measure the impact of each project and make sure its getting you closer to the destination.

The next question to ask is:

What’s the quickest route to the destination?
This is what roadmaps are all about – knowing your destination and planning how to get there most efficiently.

Once you understand the goals, then get your stakeholders in a room and chuck ideas up on a whiteboard.   Rank each as high/medium/low impact – based on how close they get you to your goals.  Then rank each as high/medium/low difficulty – based on how long they will take to deliver.

The high impact, low difficulty projects are a no-brainer
Now you can start to plan the roadmap against your goals.  There will be dependencies between features and SDP (software delivery platform) projects needed to support customers, operations, billing etc – but you can prioritize the projects with high impact, low difficulties first, then the high/med and med/low projects etc.

Communicate the roadmap based on the goals
Its good to keep your goals in front of everyone and show what goal each project is working towards.  The roadmap below shows goals as ’swim-lanes’, with release milestones marked along the top.  Some people like to give each release a code-name – I like to give it a theme, which sets people’s expectations about what’s in the release (ie: yes – hooking up the twitter API is a great idea, we’ll look at it in the networking release)

Roadmap template

This has become quite an effective template for visually communicating priorities between projects, how our roadmap is meeting our goals and how there are dependencies from release to release and between product and SDP.

If you’d like to have a play with your own roadmap, download this roadmap template for Microsoft Visio and fill in the blanks.  Let me know how you get on via comments.

The whole point of product development is to regurily deliver quality software to customers.    Seth Godin is always saying to spend your marketing budget on engineering and build a product that people will talk about.   

This is the basis of permission marketing: build a remarkable product, tell a story to a sneezer, they will spread the word, people will come asking for more.  This starts with building a product that’s worth remarking on, which you can do by accident or you can be intentional about.  Keep in mind that often users will ask you to copy your competitors, which isn’t very remarkable.

Understanding and managing your roadmap helps you to be intentional and ensure that you are solving the right (and most profitable) problems for the right people, so the final part of the process is simply to deliver.

One thing that always needs to be kept healthy is the back channel.  I described the roadmap as a radar, giving a point in time reference of the priorities.  The back channel is the off-the-radar stuff that just shows up and is either a no brainer or is very high value with very little effort.  There will always be quick wins that can and should by-pass the entire process and get straight into the software.  These quick wins are only possible when the rest of the process is operating smoothly, they’re the exception to the rule.

At Xero, our mantra is to release early, release often.  Delivering software into the hands of users builds momentum and satisfaction for both customers and the development team.  And don’t forget to have fun.

Read the whole series
Product Lifecycle: Part 1 – solving problems
Product Lifecycle: Part 2 – scope
Product Lifecycle: Part 3 – the roadmap
Product Lifecycle: Part 4 – delivering

Scoping a feature into a project is one thing, but scoping 50 features into 200 projects that deliver on the strategy of the company becomes a roadmap.  You can take this to extremes and try to plan out the next 2 years or take the other extreme and focus on just the next thing.  Agilers say we should delay decision making until the last responsible moment, but there is a difference between decision making and planning.  

I think its diligent to plan ahead 3 months, but with the understanding that the roadmap is like a radar – its a blip that’s only accurate at the point it was created – but once we have this reference point, its much easier to see changes and to comminucate priotities.   

At Xero, we use two levels of roadmap, but I’ll explain it as three, because the first two (buyer & product) are very specific to your product offerings.

Buyer Roadmap
Managing a separate roadmap for each buyer persona helps keep in perspective who you are solving problems for and helps to prioritise features for each buyer persona.  

Product Roadmap
You may have a 1-1 buyer-product mapping or one buyer for many products or many buyers for one product or many buyers for many products.  How you productise your software is a strategic decision and managing a product roadmap helps keep your strategy in perspective.

Company Roadmap
This roadmap is the convergence of the product roadmaps into one roadmap that can be communicated to the company without getting overwhelming.

At Xero, we present our roadmap based on the current goals that we’re aiming for.  For example, one goal is to be the easiest accounting system and there are projects we do to serve this goal.  Another goal is to achieve customer numbers so there are different projects we do to serve this goal.

Product Lifecycle: Part 1 – solving problems
Product Lifecycle: Part 2 – scope
Product Lifecycle: Part 3 – the roadmap
Product Lifecycle: Part 4 – delivering

Scoping is about two things:  understanding the bigger picture and saying no.

You have to say no to 100 things so you can say yes to the one right thing.  Some people say ‘good is the enemy of best’ – ie saying yes too soon means you’ll settle for a good solution but not the best.  Others say, ‘best is the enemy of good’ – ie if you strive for perfection you’ll never deliver anything, so its better to get something good out the door.  

Both are true, so how can you make such calls if you don’t have an understanding of the bigger picture?  Of course there’s always a bigger picture to the bigger picture, but that’s important too because eventually you’ll work your way right back to the company’s strategies and vision.

To make good decisions and to empower yourself to say no 100 times, you need to know where an idea fits.  9 times out of 10 you’ll hear a solution before you understand the problem, so you need to start by working back to the problem, then understand who the problem applies to, then understand what the solution is, then understand what the ideal solution is and how that fits in with the rest of the product.

Once you understand how it fits (and this is usually a thought process or a discussion – not a meeting or a document), then you can start to scope it back to a deliverable project.

At Xero, we tend to deliver a feature in stages of:

Entry level – get a solution into the hands of users so the feedback can begin.  80/20 rule applies.

Easiest – our goal is to be the easiest accounting system, which means supporting some edge cases and hiding complexity.

Automated – we save users time by removing tasks that they shouldn’t have to do manually. 

Innovate – once we have a great solution and really understand the problem domain, we can introduce game changing innovations.

We only design one stage at a time and the next stage will be designed based on user feedback.  Each of these stages generally represent a project that will be scoped and prioritised into the roadmap but usually won’t be delivered in consecutive releases. 

Product Lifecycle: Part 1 – solving problems
Product Lifecycle: Part 2 – scope
Product Lifecycle: Part 3 – the roadmap
Product Lifecycle: Part 4 – delivering

I love developing software because its possible to create something of value from simply an idea in your head.  

Over the past few months, I’ve been talking to a number of people who are using agile or want to use it to build better software products. There are a lot of people using “agile” as a wild-card to implement rigid processes which often feel counter-intuitive to the goal.  

If I’ve learned two things about being Agile, its to focus on people over process and to take the agile toolset and apply these precepts over (not instead of) the existing precepts of building a good team with the right culture and leadership and using good software engineer principals.

My next four posts are a look at the bigger product lifecycle, within which sits the software development lifecycle.  The purpose isn’t to say this is the way or the best way, but to give an example of how Agile principals can be achieved in a design-led environment where the business wants a predictability. 

When you read this, keep in mind that its always about people over process so a lot of what I describe are just precepts upon which we discuss and plan the product development.  We are also trying new things all the time which keeps it interesting.  

Solving the Right Problems

Developing a product is as much about the bits that come before and after the software development.  Identifying problems, finding a solution that resonates with people, understanding the difference between buyers and users, then building it and finding the right messaging to get it into the hands of people who will spread the word.  Its so much fun and can have such a big impact on people when its done right.

Identifying the right solution to the right problem is often overlooked and when we do get this bit right (read Tuned In to learn about getting this right) – how do you build and deliver it better, faster, cheaper?  

I don’t care much for repeatable processes that get followed religously.  What’s more important is having the right people on your team, then equipping them to work to their strengths.  Process is important though because it gives us the framework for being creative.

So, lets have a look at the bit in the middle of ‘problem’ and ’solution’

To solve the problem, we kick off a project which will include some design, some development, some testing and some deployment.  This is where the debate on software methodology comes in – some people like to iterate the whole process, some like to iterate the development and testing, some like to iterate the design and some like to deliver the whole lot at once.

How you do it largely depends on the people in your team (which will hopefully be defined by the needs of your product).  If the developers are designing the app and talking to users then you can have very small iterations over the whole lot.  If you have highly structured requirements or your developers don’t have much domain knowledge, then you may iterate over the development and testing within a big project, or just deliver the lot within a small project. 

At Xero, we’re design-led, which means we iterate many times over the design (for a single project – not the whole app), then build and test in one hit.  While iterating over the design, it will be reviewed by developers, testers, users, customer care, sales people and generally anyone who has an interest.

With applications that are delivered online (which can include installed apps too), release cycles can be daily, weekly or monthly.  At Xero, we aim for about a month, but are flexible depending on what we’re working on.

Having regular releases is a great way of getting software in the hands of users and then using their  feedback to improve and extend the product.  This is also a main principal of agile to build-show-build-show and whether you iterate like this over the design or the software itself, the important thing is to involve users in the process.  At Xero, we iterate over both and I’ll discuss this more in part 2.

Life would be easy if we only had to think about one project at a time, but we usually have 10-20 projects in the works at any time and another 20-50 queued, so the prioritisation and dependencies between these is an important factor.  There are two things to look at here: the scope and the roadmap which are the topics of parts 2 and 3.

Read the whole series 
Product Lifecycle: Part 1 – solving problems
Product Lifecycle: Part 2 – scope
Product Lifecycle: Part 3 – the roadmap
Product Lifecycle: Part 4 – delivering