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:

• https://hbr.org/2012/09/are-you-solving-the-right-problem