Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Solution Defines the Problem

DZone's Guide to

The Solution Defines the Problem

Are all products, i.e. solutions, born of a problem that needs solving, or are some made simply because they can be? Read on to get one Agile expert's opinion.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

How many times have you encountered a user/customer/client who describes the thing they want in terms of Microsoft Excel? - "What I want is a macro in Excel to pick up all these data points and then..."

Many a Business Analyst has started from this point and worked back to discover what the clients real "problem" is. Quite possibly the client never considered themselves as having "a problem." Quite possibly the "problem" would never have been spoken about if the client didn't have an understanding of spreadsheet technology. And in the days before spreadsheets were invented the task may have been tiring, time-consuming, and prone to error, but, that's just how it was.

Regardless of whether Excel is the solution they finally get, or not, it is only because they can imagine a solution, that a problem can be defined. In fact, the Solution defines the Problem.

Excel is not the only example...

I was traveling on the London Underground the other day when this advert leaped out at me: "Estimated bills got you in a spin? Get accurate ones with a smart meter." What?

Really, I mean: What?

I've been paying electricity, gas, and other metered bills for over 20 years, not only have I never "got in a spin" about an estimated bill but I've never given it two thoughts. Neither can I ever recall anyone saying to me, "Gee I hate estimated bills... they are so much hassle..." OK, maybe some people have but so few that it hardly ranks as a world-class problem.

Actually, now that I think about it, I prefer estimated bills. It is a hassle having a meter reader come to the door and having to show them the meters. And it is even more of a hassle reading my own meter, finding the box key, writing the reading down, trying to log into a website, doing "forgot my password," etc.

This advert, this whole product, is a great example of Solution Defines the Problem. Estimated bills are not a problem until you to have a solution.

Yes, I know Solution defines Problem is heresy to some. We are supposed to find the problem and work backward from the problem to the solution, outside-in.

Yes, I know that all you Business Analysts and Product Managers were trained - as I was myself - to look for the problem and then define a solution: a solution that might just happen to be technology based, and might just happen to be software.

And, yes, I know that to many of you the idea of a company creating "a problem" so they can then solve it is morally repugnant but... let's think about it for a minute.

What problem does the iPhone 8 solve? What was at the front of Apple's hive-mind when they designed the iPhone 8?

And what problem does the iPhone 8 solve that the iPhone 7 didn't solve? Or for that matter the iPhone 6? 5? 4?

(I mean "what customer problem," one could argue the problem the iPhone 8 solves is Tim Cook's need to have more sales revenue).

Solving problems is not enough.

I'm not saying outside-in, problem-first, innovation, and development doesn't work. Clearly, such an approach has worked in many cases. What I am saying is: it is not always appropriate; sometimes a more effective way of working is inside-out.

What can the technology do?
How can we make people's lives better with this?

This approach too has a number of success stories. Rather than condemn it as "wrong" maybe we should be asking "When and where does it work?" and "Which approach is the most appropriate?"

When creating a new thing - be it software, hardware or services - our understanding of the problem evolves as our understanding of the possible solution, or solutions, evolve. One starts off thinking of a solution or a problem, we seek to understand some more - maybe by building part of a solution or by talking to someone we think has the problem, we learn a little, maybe we continue in this mode or maybe we flip and work on the other side of the equation. And round we go again, iteration.

It is a learning cycle, the question is, what is the fastest way to learn?

I included the solution-problem hypothesis in my Agile Cambridge keynote last month. Afterwards, I was e-mailed by someone whose email I've now lost (apologies!) and recommended a book: Overcrowded by Roberto Verganti.

Roberto Verganti takes a similar but different approach to the same question. For him, the key is meaning. At first, I wasn't quite sure if "meaning" was the right word but as I've read more I think it is, albeit meaning in a fairly broad sense.

Verganti's argument isn't quite the same as mine but it is close enough, he is also arguing for starting with a solution and working backward. For him the aim is to create new meaning, you might say that he identifies a generic problem, "Human needs more meaning in their world."

Try the iPhone test in this context too: "What is the meaning of the iPhone 8?"

I'm going to be talking more about this in my keynote to TopConf in Tallin next month, in the meantime please let me know what you think. Madness?

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,agile development process ,agile practices

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}