Over the past few months, I’ve worked with numerous clients with amazing ideas. No matter the company’s size, they had one thing in common: a fairly defined concept of what their product would look like, and an eagerness and sense of urgency to start writing code.
I’ve consistently pushed back on these clients and have advised them that the last thing we want to do is to write software for them. At least, not right away.
The problem with starting with code:
Previously, we asked our clients to have well-defined requirements to hand off to our development team. That used to be enough to get our teams working and deliver exactly what was asked for. Writing quality software used to be the first thing to do: Maximize output, optimize velocity, show value to the customer.
But in many cases, this did not end in what I consider success because delivering exactly what we were contractually obliged to did not not necessarily translate into user adoption and happy clients. Far from it, actually. And whether or not our dev teams delivered what was ordered became irrelevant. The products failed, and it reflected poorly on us.
In recent months, we’ve adopted a different approach. Instead of taking our clients’ ideas, concepts and requirements at face value, we partner with them to validate a number of things first:
1) Have you clearly identified the problem(s) you are trying to solve?
We discovered that a client’s envisioned solution tried to address multiple problems for a variety of stakeholders, leaving them unclear about what the true problem statement was. This almost always resulted in a finished product that missed the mark.
2) Does your envisioned product address the most pressing problem(s)?
When we partner with our clients to really dig deeper into their problem space, we find that in many cases, the most apparent problem may not be the one that has the biggest impact on the bottom line. By deconstructing the problem space first, our clients can more clearly see their biggest obstacles and where to focus when devising the solution.
This exercise typically results in finding a number of related and/or unrelated problems that are also worth solving. It is the clarity of this inventory that allows us to be smarter about where we focus our efforts first.
3) Have you validated that the approach you have taken is the right one by putting a prototype in front of unbiased users?
Products are conceived with the very best intentions, and sometimes clients have done quite a bit of due diligence in defining and exploring the problems they are trying to solve. But adoption of the solution is ultimately what will define whether or not a product is going to be successful. In order to be confident that the direction you are taking is going to be successful, you need to watch unbiased people react to what you envision building.
People often approach me with confidence in their product, because they have validated with friends, family and co-workers that their idea is brilliant. It may be brilliant indeed, but you won’t know for sure until you put it in front of people who don’t care about the people behind a product. The product needs to stand on its own, without a sales pitch, and without pressure. That’s why we insist on putting a prototype in front of people to gauge their reaction to what we will be building, before we write one line of code.
This new approach has been eye-opening, both for us as well as for our clients. We have conducted several workshops where these three questions are addressed in depth, and each time our clients have come to some sort of epiphany about their envisioned solution. They have changed product direction for the better. It has allowed us to become partners for our clients, each with a stake in the success of the product. Knowing that we are addressing the right problems, and that our envisioned end-users will actually be using our products puts us in a much, much stronger position to build a product roadmap to true client success. And once we have that validated product roadmap, we’re finally ready to confidently do the last part: to write software.
Recent Comments