Dual-track Agile in B2B

Although dual-track agile does not guarantee that your product / brand new feature will be successful, I consider it the best approach to minimise the money wasted. At least, I would not recommend you to follow other strategies if you risked your own money.

The B2B world, however, is often too muddy for the scientific methods that lay in the foundation of dual-track agile. Salespersons must convince C-level executives to buy their products, while the actual users may or may not have a say in the deal. Therefore, a product might be useful and usable, but if it does not convince those who have the right to make contracts, it will never be sold.

This logic also works the other way around: if a product is useless and painful to use, it may still produce considerable sales figures. The problem arises when selling new features / versions of such product: after executives learn that they spent money to something which is not used in their organisation, it will be highly unlikely that they will invest into it in the future.

Reducing waste by dual-track agile

Dual-track agile can help the players of B2B to develop useful and usable products, that can become essential tools of their users, and make money for the customers and suppliers. These are the key elements of the strategy:

  1. Charter user program: Work together with 6–8 customers / users (e.g. 1–2 users per customer) from your target market. Regard them as development partners, who, just like you, are striving for the success of the product.
    I usually had 6 charter users whom I could turn to with questions, whom I could invite to demos, and whom I gave access to demo systems so that they could play with the latest daily build. This relationship was beneficial for both of the product and them, since we developed the right features which had been successful beyond the organisations of the charter users, and the charter users could influence the course of development so that they could get the features they needed earlier.
  2. Metrics related to the business case: You will want to know if a change in the product is really worth to be implemented, and you surely don’t want to make the decision based on gut-feeling or any other occult approach. To make objective decisions, you need to define metrics, which relate to the business case of you product. Do you aim to make more efficient the workflow of you customers? Measure time needed to complete their workflow! Do you aim to generate more new leads? Count the number of leads!
  3. Measure / observe / work together: To develop useful features, it is not enough to ask the customer, what do they want. Well, it is not only insufficient, but in almost all cases, it leads to a product stuffed with features which are not used by event their requestors. Instead, focus on the problem of the customer, explore it, collect data and measure (e.g. time needed to complete a task, number of certain operations). The best ways of identifying problems and collecting data are observation and co-working. You can get first-hand information about the issues your customer faces and the extent of those issues.
  4. Validate the opportunity using the collected data: After you have collected the problems and the related data, you can calculate the value of solving those problems. You also need to factor in the potential customers: for example, certain problems may exist only at a handful of big customers, while others might be present in hundreds of small customers. You shall reject an opportunity (i.e. shall not solve a problem), if its quantitative business value at the potential customers is lower than a pre-determined threshold.
    Another, simpler opportunity validation approach is based on the willingness of cooperation: will a potential customer spend time (and therefore money) to solve a given problem (e.g. dedicate 1–2–3-… full-time employees to the cooperation)? If the answer is yes, the problem is most probably burning enough to be valid, especially if it also exists in other customers.
  5. Validate the solution by working together with charter users and using a prototype. Yes, you must to use at lest a cardboard prototype to validate a GUI-based solution. 
    You can measure the quantitative value of the solution; for example, you can measure, how fast can a charter user solve a problem with the prototype, and how is it compared to the current problem solving efficiency. After the comparison you can decide if the solution is good enough, i.e. if it delivers the desired amount of value.
    The value of the solution comes from the usefulness and usability; both can be measured / calculated and shall be tested. Generic usability tests (e.g. will they find a new button, menu item?) can be conducted with even your own colleagues, while charter users shall be used to test more domain-specific changes.

In case of all those product development projects where we followed the above approach we managed to maximise the value we delivered to our customers. Sometimes (often? always?) it requires to fight against the organisational silos, and/or even violation company policies. It is a tiring, meticulous approach which is deeply influenced by scientific thinking (i.e. make a hypothesis, design an experiment, conduct the experiment, …). You might be tempted to be a visionary reincarnation of Steve Jobs who listens to his guts and jumps into the solution phase right away after the morning coffee, but if you want to develop a really successful product which is both useful and good to use, it is not enough to

  • convince the executives,
  • rely on your guts (seriously, use your brain, and the industry best practices!),
  • ask your customers what do they want,
  • take the tenders as requirement specifications,
  • sell your time to your customers instead of developing a product.