The use defines your product

 
The use defines your product
  • … Will you deliver on time?
  • … What percentage have we already delivered?

We usually hear these questions when we’re involved in software development.

At first glance, they appear inoffensive enough, but when you observe the behavior they cause in people, they can discourage the impact and value that organizations seek so much. 

In such scenarios, you often find a lot of time and money being spent without the expectation of a significant impact on the company strategy, and even on the client’s necessities.

When questioned about the non-delivery, teams find ways of justifying the bad results with: “we just need more time” or “our end is all ready, we’re just missing…”, delaying any decision for value delivery and further burdening the company’s budget.

After observing several organizations in such scenarios, we’ve identified a few common problems:

  • The high cost of coordination: living in chaos: never-ending e-mails, overdue deadlines, meetings in order to arrange meetings, in other words, we spend most of the time working to justify the non-delivery, rather than working to deliver.
  • Loss of learning: since the focus is to deliver things in a set time, people don’t know what problem they’re trying to resolve or the impact on the business, generating a short-sighted vision of the purpose, and consequently reactive teams (always waiting for the decisions of their superiors).
  • ROI absent: the sensation of completeness based on activities concluded and not on value deliveries to the client. Without value delivery to clients, there is no ROI.
  • Stocked software: the functionalities built aren’t in production. There’s no use, without use there’s no feedback, without feedback we don’t know we’re on the right path.

And what if the team’s efficiency weren’t a problem? If we had the best team in the world, would we be delivering value to the client? There is only one way to validate this: delivering and collecting feedback in short cycles.

“Use defines your product” (Rafael Sabbagh)

According to this way of thinking, it’s clear the problem doesn’t lie in the team’s efficiency but in the efficacy of the deliveries. In other words, we must deliver something of value and with impact to the client, then they will use the product and only then can give feedback about how near or far we are  from resolving his problems.

Theodore Sturgeon, the science fiction writer, said that “ninety percent of everything is crap”. This makes total sense for the development process of software products. How much time and money is wasted on building products that no one needs? To eliminate or minimize this scenario, we must urgently change the traditional approach to development, focus on the relevant 10% and generate impact for the client:

Love the problem, not the solution

Understand the problem you’re trying to resolve: what it is, who feels it, when does it happen… Don’t get lost working on marvelous solutions to problems no one has.

Do something useful

When you know the problem profoundly, think of a simple and fast solution, which needn’t meet all the criteria, just the root of the problem. It can even be a temporary solution, but test its use with the user and ask for feedback.

Measure progress based on value delivery

Success isn’t ticking a box

Success is having an impact.

If you’ve finished all the tasks and nothing improves, that’s not a success.

@cwodtke

What does 90% of something which doesn’t work mean? NOTHING, absolutely NOTHING. The way out is to focus on something tangible, which causes an impact on the business and the lives of the clients.

Read our other post to find out more:

“When will it be ready?” isn’t the most important question

Did you enjoy and identify with these tips? Leave a comment!

«
»

Leave a Reply

Your email address will not be published. Required fields are marked *