Business Savvy Software

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