Customer Driven Product Development A Report From The Trenches

Customer Driven Product Development A Report From The Trenches

I have recently been approached by a good friend of mine, Wojtek Pander, and asked for a contribution to his research paper on Open and Customer / User-Driven Innovation. I immediately thought the best we, here in Selleo could do to contribute, would be to share our very down-to-earth insights gathered together from our clients on over 30 software development projects. I also knew that the focus would have to be on the customer / user involvement in the software development process, i.e., the front-end part of the process which is usually controlled by the client rather than their vendor, who are preoccupied with technical product execution.

Our clients – the product owners – varied widely in their approach towards customer/user involvement in the process. Some of them got their customers engaged very early on and kept collaborating with them fairly intensely; those clients consistently verified their own assumptions against the feedback and data gathered from their target group and used the input to manage their product scope. Others were less willing to do so; they chose to manage their products by themselves. In some extreme cases the product was first exposed to the customer only after over 12 months from the project kick-off.

Though the number of clients we have served does not allow us to draw significant statistically valid conclusions, the pattern that has emerged is quite clear. In a nutshell, we have observed that customer / user engagement in the design and development process allows the elimination of, or at least the reduction of, a number of risks and increases the odds of market success. The products developed are better and they are more likely to fare well in the market. Needless to say, not doing so has the opposite effect. Not surprisingly, our observations are borne out by a number of accounts we have heard from developers working for other software development houses. The pattern seems fairly consistent.

(From now on I shall stick to the term “customer”, though it is worth bearing in mind that it is not always synonymous with the user; depending on the type of solution, you may have to deal with customers who are users or else with separate groups of customers and users. When I refer to the “customer”, I broadly mean both groups, i.e., all those for whom a given solution is to be created.)


What you risk when you are not customer-driven in your approach

Those who design and implement their solutions without customer involvement or engage their customers late in the process are very often confronted with the following phenomena:

1. Lack of / poor product market fit. They often implement solutions which find no / too few customers and, as a result, do not generate revenue which allows them to recover their investment. In an extreme case, when the first customers were eventually approached with the product, it turned out they perceived it as a threat to their market position rather than an opportunity to exploit. The sales attempts were futile.

2. Solutions burdened with extraneous features. The systems very often get loaded with features and functionalities the customers never / hardly ever use, let alone are ready to pay for. It needs to be stressed that such irrelevant features can have a negative impact on the ease of use of those functionalities that the customer does need.  Thus the former may decrease the overall value of the solution. In one case, a target customer actually agreed to purchase the solution as long as the provider agreed to simplify the product by removing a number of features implemented and available in the product. Classic waste.

3. Products loaded with unnecessary complexity. Some build solutions which are much more complex than they really needed to be.

4. Laborious late-stage modifications (rework). Those who fail to listen to their customers often fail to correct their course early on and risk having to do so late in the process, e.g. after the product has been shipped to the customers. In principle, the later you need to modify the solution, the greater the workload and cost associated with the change.

All the phenomena mentioned in the points above lead to:

5. A significant increase in development expense, including the costs of QA. We should stress the impact of the cost of complexity and emphasise that the cost is exponential rather than linear in nature. When system complexity increases, so does the cost of enhancements and support. Thus extraneous features not only generate costs associated directly with their implementation but they also increase the costs of introducing features and functionalities in the later stages of product development. Litter the system with trivia and you may close the way for what is truly needed.

6. Increased cost of system support and maintenance.

7. Increased cost of delay and the associated market risks. Applications built without customer feedback often take longer to develop and launch. It is particularly destructive in the case of innovative projects where time is a very sensitive issue. Delays significantly increase the risk of market preemption by a faster competitor or at least lead to a decrease in the market share that can be monetized. In one case, we saw our client working in the back office on milestone 7 while their competitors were releasing products with only 20% of the functionality we already had in our system.

8. Increased technology risks. Delays in implementation increase the risk of changes in the underlying technology. Take too long to develop the product and you may discover you need to implement modifications you did not (and could not) plan for.

9. Negative impact on your team’s motivation, engagement and productivity – increased risk of attrition and knowledge loss. This negative impact concerns both your in-house team and the vendors’ you are using.

10. Negative impact on customer engagement. By getting the customer involved you facilitate the adoption of your solution. A sense of ownership which stems from collaboration helps a lot when the solution is to be applied by the customer. Fail to engage the customer and you may find out it is much harder to win the customer over when the solution is to be deployed.

All in all, when you eliminate the customer from the design and development process, you are very likely to be confronted with a number of phenomena which increase the odds of failure on your project. What – specifically – can you do to increase the likelihood of success then?

Success Story – Frontal Solutions AS and the Metreno Platform

Frontal Solutions AS is a Norwegian consulting company providing services and software solutions which facilitate their clients’ HRM functions and internal communications systems. They deliver their services to medium-sized and large enterprises. One of the solutions is the software platform Metreno which is used to manage HR surveys and internal communications measurements.


The platform was designed, developed and implemented in very close collaboration with Frontal Solutions’ target customers. The latter were involved in the process from a very early stage of product design, and the systematically gathered feedback they provided in successive product iterations has enabled Frontal Solutions to efficiently deliver a solid software tool which addresses very tangible problems their customers are confronted with. Frontal Solutions have been using the following methods to get their customers involved in the design and development of their software platform:

  • the initial product concept and project scope. was developed, or should we say – co-created – together with their target customers. The customers played a vital role in defining the problems to be solved, specifying the high level requirements for the solution as well as prioritizing specific modules, features and functionalities to be implemented.
  • it should be stressed that to the extent possible, Frontal Solutions prefer to avoid using structured interviews and rely on more open, dialogue-based brainstorming sessions to better explore the opportunities to take advantage  of and the limitations to neutralise. The formula ensures that both sides are equally equipped to contribute valuable insights in the process. It is only in the future, when the product functionality solidifies, that Frontal Solutions intend to use a more structured approach to gathering feedback.
  • more detailed technical specifications, especially visual mockups (!), developed for successive iterations by the Frontal Solutions team, are verified with the customers. The approach enabled Frontal Solutions to introduce changes very early on, i.e., before development started.
  • having implemented a module or a set of functionalities, Frontal Solutions carried out acceptance tests together with the customers to further ensure compliance with their customers’ requirements and expectations. The co-testing, among other things, helped Frontal Solutions verify some of their assumptions concerning what “user friendly” really meant for their customers’ users. after each module had been deployed in the customer’s production environment, the customers/users provided valuable feedback that has continued to guide Frontal Solutions in their decisions to modify, complement and optimised the solution delivered. In principle, the less standardised the module or else the more innovative the solution, the more intense the collaboration that is needed.
  • Frontal Solutions have also used analytic methods to optimise Usability / User Experience, specify the requirements concerning browser compatibility and schedule of activities meant to increase the performance / scalability of their application.

Frode Jakhelln Laugen – Frontal Solutions founder and Managing Director, is convinced that the adoption of such a customer-driven approach has allowed his company to:

  • build a solid solution which has found paying customers. A good product that meets the target customers’ needs is the best facilitator in the sales process, and with the customer involved in your product development process you are more likely to arrive at what the customer considers to be a good solution,
  • increase the level of customer satisfaction as well as stimulate the customers’ sense of ownership, which leads to customer engagement in the implementation phase. Customers are more likely to accept a solution they have co-created rather than a solution that is “imposed” on them,
  • avoid (reduce the number of) late-stage modifications, a lot of rework and the associated costs,
  • avoid the implementation of features and functionalities which bring little or no value to their customers. This in turn allowed Frontal Solutions to limit the complexity of the system and reduce the investment outlay needed,
  • shorten the implementation cycle and deliver what the customers were after much faster. A modular product architecture and a matching pricing model used have enabled Frontal Solutions to speed up revenue generation and thus allowed the company to partially refinance the further development of their product,
  • increase the level of motivation on the product development team,
  • it should be noted, though, that customer involvement does require effort and takes time and as such is associated with upfront costs; the investment, however, pays off later on in the product life cycle.


The benefits of the customer-driven approach.

Allow me to reiterate the key points. Properly engaged customers and/or users provide insights and invaluable feedback which helps you to verify initial assumptions and better manage the product scope. Proactive customer involvement allows you to:

ensure better product market fit and higher customer satisfaction, which increase the odds of generating the sales with which to guarantee return on investment, make the decision to discard the project or pivot much earlier, saving you the irrecoverable cost of walking down a blind alley, verify your assumptions and introduce changes in the early stages of product development limiting expensive rework further down the road, significantly reduce the risk of implementing extraneous features the customer will never / hardly ever use; thus you lower the cost of development, support and maintenance, including the cost of complexity, shorten the time to market, lower the cost of delay and eliminate some of the market and technology risks involved as you have less workload on the plate end up with more engaged customers, co-workers and suppliers.


Some entrepreneurs / Product Owners concentrate primarily on building technical specifications and collaborating with their product development teams. In doing so, they significantly limit their customer-focused activities and thus miss an opportunity to gather invaluable customer feedback with which to build a better product faster. Such an approach increases the likelihood of failure. Short and bitter. If you intend to build an innovative product / venture, strive for early, intensive and consistent customer involvement. Define the role of the customers in the process upfront and stick to you plans. Get the customers involved in the specification, design and implementation of your solution. You should:

  • verify your product concept and initial project scope with early target customers,
  • engage them when working on requirements and specs,
  • seek their feedback on successive product iterations.

When possible, accept and test new deliverables with the customers and use their feedback to review your backlog priorities and schedules.

All in all, if you are after innovation, seek customer involvement in the process. As a rule of thumb, the bigger the market risks, the greater the involvement needed. Do not stay locked up in the ivory tower of back-office product development. Many technically splendid products have never found the customers they were meant for. I actually wonder whether there is an alternative to the customer-driven approach. I mean, a more effective alternative.

Post Scriptum

Practical tips on how to build and develop software products and ventures based on customer / user feedback can be found in publications and speeches by, for instance, S.G. Blank, E. Ries, A. Maury, D. McClure, S. Ellis, A. Chen. If you are after short narratives by tech entrepreneurs, I recommend the illuminating case studies and tips you may find in Do More Faster.