In technology — software in particular — it’s easy to add features. And people love writing use cases. But don’t start with those. Start with the need and the problem.
Clear problem statements are the beginning of feature planning. A good problem statement is the gatekeeper that should decide if a use case gets written. The benefits to this are many.
- By the time you get to a use case, people have typically started baking in subtle assumptions.
- Moreover the agile tools that are great for software development don’t always translate to investigating business and real world people needs.
- Ask yourself, how do you even know if a use case that was written is any good? What is it being benchmarked against?
See my case studies for real examples from my career on how I’ve learned to help management teams, businesses and products focus on core issues.
What to do
Need and Problem Statements can be managed simply. Asking the executive to wade through page-long use cases and Agile epics just so they can decide if they even need to know about what’s in them is inefficient.
Need and Problem statements can be cross-referenced, compiled and managed using portfolio methods. Once we have enough of them, patterns emerge.
Moreover, it gets us away from ‘one button per feature’ that ruins user interfaces. It gets product teams focused on adding value. The benefit is also for the sales and customer support teams. They stop trying to design features that may be about the office procedures used by specific clients.
Needs and Problems
I need to eat. However, it’s not a problem unless I don’t have food.
Needs and problems are not the same thing and throwing a rope around these has, I have found, brings clarity to product planning. Here’s another example: Tony Stark wanted to live a life of luxury with no responsibility. The moment he realized that this was actually not his need but his problem, Stark began to grow.
Let’s say the customer says ‘I need your product have a new tab for end of shift reporting’.
Most of the time, we’d throw it into a reporting epic.
What if we instead pin the request down as a need statement with an accompanying problem statement? We may learn that the person is actually telling you something about their office procedures for regulatory reporting rather than something that needs to be made into a button.
- Who has the need?
- What is the need?
- How is it a problem?
- For whom is it a problem?
If we keep digging we may learn that some additional minor data integration may solve the problem but the person making the request was only looking at a small section of the picture and choosing the solution — a report for transcription — without understanding the problem. Or the bigger picture. What they were looking for may exist elsewhere or may become less important with an alternate point of view.
This example of a report being requested is a real world one. We became so fixated upon getting them a solution that we did not understand how it was a problem and for whom.
My solution for you is problems.
Business Analytics
Look at my case studies to see how I’ve used my method to create business analytics and features that have pushed products and companies forward.
