- 3 November, 2020
- Article - Uncategorized @gb
During development, we often forget how important it is to spend enough time exploring and understanding the full context of a problem before charging ahead with new ideas, “game changers” and designs.
Time and budgets are frequently wasted on building (and even perfecting) minimum viable products (MVPs) and tech demos, before the actual problem has been adequately explored and understood.
A central issue that the meaning of the word “requirements” is twofold, and is usually understood as both the customer needs and product requirements. They are written interchangeably without clarifying which one is being addressed or what exactly the differences are.
The suggestion here, is that technology teams must diligently unpack the constraints and customer needs before focusing on the solution. Here are 4 reasons to take this seriously.
Create an even granularity of concerns to address
Breaking the overall vision, history and strategy into smaller, digestible requirements, shapes a solvable puzzle that has less contingencies. Deconstruct the subproblems within the requirements to create a functional map to start from.
It’s also important to remember that the point is not to solve the requirements exhaustively. Explore the problem space fully, but the solution space should have just enough coverage to kick off. The solution will change and evolve as you go, but the problems will mostly stay the same.
The less contingencies you have, the easier it is to create accurate estimates
Less contingencies means more accurate time and resource estimates. If you spend enough time listening to what the business needs, you sometimes realise that you don’t even need a solution or that the results you need are completely different to what you’d expect.
Spending time and exploring business context, history, competitors and strategy takes patience and rigor. Working on the solution is more appealing because it’s new and unchartered. But when too much focus is placed on demos, planning new workflows and designing MVPs; time and budget end up wasted on redundant features.
Technology teams have the ability to detect more complex problems
Your engineering teams are experts in their field, and have the ability to help you find and unpack hindrances that the business might not be aware of. The business team and tech team need to spend time together in this space to discover these complexities early on in the project roadmap.
Use this time to collectively map out the business context, vision and landscape in detail so that both teams are able to answer questions in future, and can become self-sufficient. If everyone fundamentally understands what the business requirements are, they can short-circuit themselves by having the information at hand.
Showing empathy will create customer buy-in
Spending more time truly understanding the business context and constraints of the environment demonstrates empathy. Engineering teams need to show the customer that they care about their vision and objectives, and that they’re putting themselves into the customer’s frame of reference. It’s a relationship-building exercise that gives the customer confidence in their abilities.
As an analogy, consider visits to the doctor. The doctor ideally takes an interest in examining your worries and exploring the causes with you. The added time and patience the doctor takes to listen to your concerns, understand your background, and interpret how you feel, is what instils confidence. When you feel listened to and know that the doctor has all the information needed, you are more inclined to trust the diagnosis. The same is applicable in any complex problem-solving relationship.
“the point is not to solve the requirements exhaustively. Explore the problem space fully, but the solution space should have just enough coverage to kick off”
As engineering teams, we are naturally more drawn to the interesting and magnetic work in the solution space, and sometimes skip over the problem space without even realising. However, putting extra effort into exploring the business model and success criteria to detect hidden complexities, unpack granular subproblems, create better estimates and show empathy will result in a solution that solves actual problems when it is ready.
As engineering teams, we are naturally more drawn to the interesting and magnetic work in the solution space, and sometimes skip over the problem space without even realising. However, putting extra effort into exploring the business model and success criteria to detect hidden complexities, unpack granular subproblems, create better estimates and show empathy will result in a solution that solves actual problems when it is ready.
Related Articles
