By the time a business problem reaches a developer, it’s already been turned into a solution.
A company decides it needs a new website because the current one looks dated. A department asks for a custom application because an existing tool is frustrating to use. A leadership team wants automation because a process takes too long. All of these ideas seem reasonable, but a proposed solution without investigating the real problem is still just an assumption about what will fix the situation. If the assumption turns into a plan, the actual problem may remain unaddressed.
Before making software decisions, you should understand what isn’t working, why it isn’t working, what outcome needs to change, and what your options are. Development should come after you work through those questions, rather than being the time when you discover it. Answering these questions upfront gives you space to change direction while it’s still cheap. Answering them after development has started can cost you months and leave you with a product that doesn’t solve the problem you actually had.
A Solution Can Hide the Real Problem
Say a company tells you, “We need a customer portal.”
Sounds specific enough, but it doesn’t explain the business problem. Why do customers need a portal? What are they trying to do that they can’t do now? What’s actually broken today?
Maybe customers keep contacting support to ask about order status. A portal could help with that. The real issue, though, may be that customers just aren’t getting clear updates after they place an order. Better email or text notifications would solve it without giving them something else to learn to navigate. Or maybe the order status isn’t the issue at all. Customers may have issues finding information about returns, billing, or product availability, which indicates a content or navigation problem.
In this scenario, the proposed solution was a portal. The real problem might have been something else entirely. Early research, such as reviewing analytics, reading customer feedback, talking to people on the front lines, or watching real users go through the process, can give you a clearer understanding of what’s actually happening. Research helps you learn enough so that you’re not building on top of a misunderstanding.
Define the Outcome Before You Define the Features
If you start a project by defining the features you want, it’s easy to lose track of why the project began in the first place.
By asking the right questions to get to the real problem, you’ll know what any feature needs to accomplish to be worth building. This will keep you from getting tied up in the “shiny new buttons” and locked onto your main objectives.
Remember, an improved business outcome is your goal, not overloading your users with features that don’t create measurable impact for them or your business.
If you want to learn more about business outcomes, read our previous article on deliverables vs. outcomes.
Establish a Baseline Before You Try to Improve It
While we’re on the topic of measurable impact, let’s take a moment to talk about baselines. It’s hard to prove something got better if you don’t know where it started. For example, if your goal is to automate a process to save time, you should know how long it currently takes.
A baseline keeps you from judging whether a project worked based on perception instead of evidence. You don’t want to measure success by feelings. A process may feel faster or easier after launch, but the numbers will tell you whether it actually improved the outcome you were trying to change.
Establishing baselines and measuring performance after launch will also help catch problems and continuously improve your process or product.
Understand the Problem from Different Vantage Points
A software problem looks different depending on who is staring at it. An executive sees rising support costs. A support rep sees a clunky internal tool they have to fight with every day. A customer sees a frustrating process that may take multiple phone calls to sort out. These may look like different problems, but they can be different perspectives on the same underlying issue.
That’s why it’s worth looking past the original request and actually seeing how the work gets done or understanding the user journey. Talk to the people using it. Watch what customers do when a process breaks down on them. Find out if employees have created workarounds and what those workarounds are, which are evidence of where a breakdown is and how work is actually getting done.
By understanding what people are trying to do, how they’re doing it, and where the current process breaks down, you’ll be more informed to make better software decisions before development begins.
What This Looks Like
None of this means you have to do months of research or discovery meetings, and it doesn’t require a dedicated research team.
Who should do this research? A manager, business analyst, or a lead developer can help lead the effort, depending on the project. The people involved must be willing to challenge assumptions, talk to the people closest to the problem, and report evidence instead of opinions.
Dig into data and analytics: Depending on what exists, that can mean:
- Web or product analysis: Where do people drop off? What features get used and what doesn’t? Are there workarounds that are being implemented already?
- Session recordings or heatmaps: If you have them, watching what people actually do can reveal a lot about how they are really using your software.
- Operational, sales, and support ticket data: time per task, error rates, abandonment rates, recurring causes identified in support tickets, or whatever is related to the outcome you’re trying to move.
- Survey or NPS responses: Read what people are saying and find patterns across the set.
What if there’s no data to dig into yet? This isn’t uncommon, so don’t panic if you don’t have all the quantitative and qualitative data mentioned above. You can start with interviews, shadowing, and direct observation. Go ahead and set up the analytics you need, such as heat maps, so you can start gathering that data.
How long will this take? For most projects, a few days to two weeks. Scale the effort to the size of the software decisions. A small fix won’t require as much as a platform rebuild.
Make Smart Decisions Before You Make the Software
The urge to build quickly or to get a solution started is understandable. It’s easy to feel like there’s no progress when something isn’t in development, but development is only worth something when it’s moving toward the right outcome.
You’re not going to eliminate all uncertainty before you start. You can ensure you have a clear picture of the problem to make the best software decisions, test whether the proposed solution is the right one, and decide what success should look like.
Then decide what to build.
