Are You Solving the Right Problem?February 26, 2020
In Art’s Principles, renowned architect Art Gensler described part of his Design Thinking consultation process as “finding the right problem to solve.” This resonated with me, particularly as I’ve thought about how Michigan Software Labs interacts with clients in the Product Strategy Phase; something I believe sets us apart from other software development companies.
With each passing year, we’ve been able to become increasingly selective about the projects we take on. Many criteria go into ensuring the right mutual fit, including budget, interpersonal connection, company culture, etc. Another one I’d like to focus on is whether we’re being asked to solve the right problem.
It would be presumptuous for our teams to decide whether a problem is right for our clients. They know their business far better than we do, especially in the early stages of our relationship. So we have to be mindful of their depth of understanding.
It’s not our place to tell them that their idea isn’t solving the right problem; however, I do believe we have a responsibility to coach them to do some due diligence to determine if the problem they have expressed is indeed the primary challenge. Clients that are likely to be a good fit for us either have done this due diligence already and are excited to share it with us, or are open to us helping them think through it in the Product Strategy Phase.
By exploring the pain points more in depth, we begin to get a sense of what the problem isn’t. Often, this is as valuable as figuring out what it is. By refining the problem statement to its core, we create the opportunity to dial in on the true, underlying problem and be in a better position to solve it.
This is how I think about a Minimally Viable Product. It’s not so much that the product has all the required features but, rather, does it solve the core problem? If you’re not solving the problem (whether it’s a user issue or a business challenge), the product isn’t viable. Who would use it if it doesn’t solve an important problem?
And here’s what sets us apart. Rather than starting at a solution, we move the conversation back to what the real opportunity or problem is and relentlessly focus on the best way to solve it. Sometimes this means convincing a potential client not to move ahead with a custom software “solution.” If their problem can be solved sufficiently with a less expensive, off-the-shelf solution, it may be better to go down that path. The ultimate problem may not be with a product; it may be a structural or interpersonal challenge. Again, it’s not our place to make those decisions, but we can work together to get to the source of the pain.
The need to understand the problem doesn’t end after the initial discovery phase. We need to continue to be mindful of it each and every day as we discuss stories and understand acceptance criteria. As a team, we need to understand why we’re working on a story, and what problem that story is solving so that we can ask pertinent questions and make sure we’re always on track. It’s great when we can propose alternative solutions to a story than what a client may have first believed. It is especially gratifying when it saves them budget or is a better way to meet the needs of the story, and ultimate solution.
There are occasions when our teams aren’t invited to discuss the problem, yet are asked to focus on the solution. This is a sure sign it’s not a good fit. On other occasions, we may understand the problem but decide it’s not the best fit for us to solve (maybe the project doesn’t carry an interesting technical challenge or it’s been solved so frequently that it’s commoditized). In those cases, we need to decide whether we can find an aspect of the project that we can get excited about or if another partner can serve the client better.
As with many businesses, we want to focus on problems worth solving. Sometimes these projects have inherent value or interest. But, more often than not, we find them worth solving because it will make a difference for our clients.
As you think about your project, reflect on what challenges within the user story you are trying to solve. Then make sure you’re aligned with those you decide to partner with. Often you’ll find that you each have some discovery to do. At Michigan Software Labs, the questions that arise from this process are valuable to our clients and, by proxy, valuable to us.
Reference and further reading:
Stay in the loop with our latest content!
Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.
2022 Best and Brightest Winners in West MichiganMay 2, 2022
The Best and Brightest Companies to Work For® competition identifies and honors organizations that display a commitment to excellence in operations and employee enrichment that lead to increased productivity and financial performance!Read more
Press Release: University of Michigan partnershipMarch 19, 2019
Michigan Software Labs announces new University of Michigan partnership to expand talent pipelineRead more
How to Build a Better App UI Architecture - Part 2November 19, 2019
Following up on the importance of consistency and reusability in Part 1, let's look at how to optimize the UI system for better consistency and reusability. We’ll begin by breaking down an iOS app, then look at how to build an interfaces-based system.Read more