Share This Post:
“The interesting thing about business, it’s not like the Olympics. You don’t get any extra points for the fact that something’s very hard to do. So you might as well just step over one-foot bars, instead of trying to jump over seven-foot bars.”
Warren Buffett
Have you been in a situation where you built a beautiful PowerPoint deck to present to your leadership, only to find them underwhelmed with the content? Was it because they were expecting more depth in the presentation, or they believed that the content didn’t cover some important topics/concerns.
Did you build a dashboard with insightful data views and visualizations that didn’t get good user adoption and utilization rates? Or perhaps you created a sophisticated capacity planning model that took quite some time in data gathering. But your leadership just wanted a simple worksheet with business heuristics-based formulae that would give the expected outcome sooner.
How does someone end up in such a situation where their solution “Just Doesn’t Cut It” with the customer?
This situation can arise due to a couple reasons:
- Misunderstanding the problem the customer is trying to solve
- Shiny Object Syndrome – Being biased towards the solution – tools/processes/features
- The value that the solution delivers is not enough to warrant the time and effort invested from the customer’s perspective
- A customer may be internal or external to one’s team/company.
It’s easy to get caught up in continuously investing time and resources into solutions that ultimately don’t meet user expectations. While it is not wrong to pursue perfection in one’s work or build a solution that one truly believes in, finding out about user discontent at the time of solution delivery is an expensive mistake. Such mistakes come at the cost of time, effort, and customer trust. Moreover, if the business needs are urgent, there may not even be scope for making such misses.
Is there a way to ensure user acceptance early on, even before any work is initiated?
In my experience, the best method is to always start with understanding the problem that one is trying to solve. You may find your stakeholders requesting certain work output that they are sure would solve their problems. But more often than not, the requested work product just resolves symptoms of the problem at hand, and not the problem itself. Therefore, in such situations, it becomes vital to ask the “Why?”. Understanding the “why” prevents us from investing time and effort in fulfilling the request, only to have the work scrapped to be started from scratch.
We understand the problem now. What next?
The next step is the solution design phase of problem-solving. The goal of Solution Design is to provide stakeholders with visibility into how their business requirements will be met. In other words, a solution design is the blueprint of the solution. Once we have this blueprint, it must be reviewed by involving the strategic stakeholders to ensure that valuable inputs are received upfront. This helps us progress in the correct direction, and hence, increases the odds of successful user adoption.
We have the stakeholder buy-in now. What should the work be structured as?
Once the initial design decisions are made and reviewed by relevant stakeholders, our work can be started to bring the proof of concept to life.
Long gone are the days when the popular practice used to be: gather project requirements, get stakeholder approval, execute the solution – hoping that nothing changes between requirement review and solution delivery, and then finally communicate with them in one of the two scenarios:
- The solution was ready to share
- Timelines need to be shifted changed
The above approach, in the software world, is known as the SDLC Waterfall model. Whether in Software Development or in non-tech project management, this approach has proved to be ineffective in gaining customer satisfaction. That said, an incremental approach to building the solution helps with stakeholder buy-ins and ensures that relevant feedback is received early on before much time and effort are invested in the wrong direction.
Yes, I am referring to being Agile – and no, the Agile approach is not just limited to the Software industry. But, what does it mean to be Agile?
An agile method relies upon incremental and iterative completion of goals with a self-managing team.
Read more
There is no fixed set of rules and tools for incremental problem-solving. The solution that is being incrementally built can take any form depending on the complexity of the problem and the stage of problem-solving. This could range from a simple flowchart to a well-built out Minimum Viable Product (MVP).
To conclude, I’d just like to assert that:
Building a product or a process must be user-focused and therefore should follow an incremental problem-solving approach. This ensures a robust feedback loop is set up with customers/strategic stakeholders, increasing the adoption/success odds.
Whether you are trying to build products, processes, or services, I’d highly recommend reading this book:
Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty