What do we do next? (Part 1)

  by Allan Mertner | 16 Sep 2008 | Permalink | Software, User Experience, Web 2.0

In a software company, deciding which one of a big pile of conflicting priorities to work on next is one of the hardest things to get right. And it is critical to the business: If your process for doing this works, you end up with products that your customers and users love and buy, whereas if you get it wrong you end up with products and features that nobody cares about.

If we can crack how to choose the next problem to work on, our engineers, designers and developers can then come up with wonderful and innovative solutions for them. Solving them in a way that is compelling and easy to use is hard, but is at least a problem that is tangible: how to best solve a particular problem within a certain set of constraints.

Somewhat surprisingly, it is much less easy to decide what to do in the first place, particularly if the market moves quickly, competitors are trying to catch up, and resources are tight. And in which software company is this not the case?!?

The framework promoted by Pragmatic Marketing goes some way towards answering the problem, but isn’t the complete answer either. They suggest that the business goes through several stages to identify what it needs to do:

• First, determine what the Distinctive Competence of your business is. Whatever it is, this is the basis for having a business that cannot easily be undercut or overtaken by another company that lacks your particular competence.
• Next, based on the DC, try to find out what problems exist in the market that you have or could build a solution for. The problems you want to identify are the ones that meet a few key criteria: a) They have to be common, b) They have to have budget/money available to solve them, and c) They have to have a deadline by which they must be solved.
• The research your Product Managers to do get here is likely to throw up a list of potential problems that can be ranked by pseudo-scientific factors such as urgency, uniqueness, number of reachable customers, value to customers, etc.
• At some point, R&D gets involved to determine whether the topmost really-valuable-problem has a solution that it’s actually possible to build in a reasonable amount of time. Yes, everyone would really like to buy a time machine, but that doesn’t mean that is where we should devote all of our R&D resources…

The above is neat, and certainly is heads and shoulders above other commonly used methods, such as when the development organization itself decides the priorities: old code needs to be refactored, libraries need to be updated, code streams need to be integrated, new platforms need to be supported, user interface needs to be redesigned use a common framework, etc. Even though all of these could be real and urgent priorities, they of course can’t stand alone. A great and well-maintained code-base by itself doesn’t make for a sustainable business.

The most common real source of priorities is customers and existing users: just build the features or fix the defects that your customers ask for, on the premise that since they pay your bills and have already bought the product, they are able to spot where it is weak or otherwise could benefit from more functionality.

The problem with this is that these people already have bought your product; by meeting their demands for more functionality, you may not be focusing your efforts on those areas that would be most effective in getting new customers to join the existing ones. At the same time, if you never do any of the things your customers want, your customer satisfaction and reputation as a company that is receptive to customer needs are likely to nosedive – so there clearly needs to be a balance.

Pragmatic also realizes that there are lots of actors involved in the process of buying and using software: the Buyer has the budget and decision power, the Technical Evaluator decided whether it meets the requirements, and the User is often stuck with what the Buyer and Evaluator between them decide is good enough.

Looking at it from the user’s perspective, it isn’t just solutions to problems that makes for great products. What problem does the iPhone solve that other phones don’t? It is unique in that it feels good, and is pleasant to look at – but I don’t think market research could have found that people thought their Nokias were particularly deficient in this regard. What we have here is a set of requirements that all relate to creating a product that it’s a pleasure to use. How many pieces of software are both helpful and pleasant to look at while being genuinely useful to the user of it? Most do what they need to do, while coming across as obtuse, unhelpful and annoying – Microsoft Project is a great example of software that checks all of the feature boxes, but in practice is horrible to work with.

To further complicate matters, your customers hopefully consists of more than just those that have paid for your product and expertise, but also includes a larger community of users that make use of your community or free versions. Having a strong community around your product offering is a great way of letting people benefit from the value of your product well in advance of actually paying anything for it – at Tideway, we have recently launched a full-featured Community Edition of Foundation for just this purpose.

Since the barrier of entry for a free version is a lot lower than when you have to pay a lot of money for it, the number of customers gets exponentially larger with a community edition – which is fantastic and great stuff! On the other hand, it also means that the list of features and suggestions that come from your customers gets very long indeed, and probably contains a LOT of useful nuggets. How do we prioritise these along with all of the other things we need to do???

Oh, and the list doesn’t end here. The Community demands and needs a place to go in order to function properly; the expectations for how well the community web site (with forums, feeds, user profiles, rating systems, etc) needs to work is high. And it should look and feel similar to the product, ideally functioning as a natural extension of the product: a dynamic repository of ideas, tips, best practices, questions, how-tos, FAQs and other enablers that is easily usable from and blends into the product.

To get this experience, the same designers and developers that develop the product should therefore work on the web site, blurring the lines between the two. And so, here is another huge source of requirements that again needs to be balanced against the others in the ongoing struggle for priority.

To recap, there are a lot of possible ways to spend your R&D budget, and you need to spend some on several of them:

• Build solutions to new market problems
• Build solutions to paying-customer problems
• Build solutions to free-version problems
• Build solutions to allow your community to thrive
• Make the product a pleasure to work with
• Evolve the architecture of the product
• Fix defects in older versions

The last two are necessary to make sure the product is maintainable and doesn’t degenerate into a quagmire of buggy, old, spaghetti code. But how much time do we devote to each of them, and how do we decide what specifically to work on in a given iteration or release? The items are of vastly different scope and are all important in their different ways! Argh!

I believe the answer requires two different aspects: A way to manage and show all of the things that are candidates, and a way to decide on their prioritisation in small increments. How to go about actually doing that is the subject of Part 2 of this topic. Stay tuned!