Focus on solutions, not problems
Software Engineering Management in 2023
In one of my previous blog posts, I outlined the situation of the tech industry in 2022/2023. Due to harsh market conditions, layoffs, and budget cuts, some engineering leaders will need to redefine their roles in an organization. I compared that situation to be an engineering leader in an early-stage startup and highlighted a few points that can be critical to their success:
- Build a team of missionaries, not mercenaries
- Focus on solutions, not problems — this article
- Grow your team, build your trust
- Go back to coding, engineering leader
- What you should expect from Software Engineers
In this article, I will focus on the practical aspect of product discovery — finding solutions rather than possible issues and edge cases.
Let’s come back to the sentence I highlighted in the previous blog post:
The role of technology in a product company is to solve customers’ problems.
It’s always easy to say, “focus on outcomes”. But if, after reading this advice, you come back to tasks in your backlog that are waiting to be groomed, estimated, and implemented, is there anything you can really do to focus on problems rather than just building features?
Do you work with requirements or hypotheses?
Being “outcome-driven” is part of the organization’s culture. This is something that should come top-down. To validate that, try to understand what your team is accountable for — delivering features or delivering value (I covered it in the paragraph “define accountability for outcomes”).
Delivering value is delivering features, but it doesn’t always work the opposite way. You can deliver features that have no value for customers. If so, you not only waste your team’s time but also grow the product’s complexity, tech debt, and future run&maintain work.
That’s why working just with requirements is risky. You assume that whoever came with them (PM and stakeholders, most likely) knows exactly what has to be done, and your engineers are only to execute that.
It’s better to assume that you work with a list of hypotheses to test rather than a list of requirements to build. In more mature companies, hypotheses will be driven by expected outcomes (e.g., grow customer base by x, get y new customers on the new market). In less mature companies, it can be the founder’s vision. Either way, your job is to test hypotheses for how to make the expected outcomes or vision a reality.
On a high level, there are two types of hypotheses for you to focus on:
- a value hypothesis (you solve real problems customers have), or
- a growth hypothesis (how fast you can acquire more customers and how to decrease customer acquisition cost).
“Problem/Solution Fit” (the value) and “Product/Market Fit” (the growth) are broadly known in the startup economy world — I encourage you to Google them.
For you and your engineering team, it means — you need to build a solution that solves customers’ problems (the value). You need to build it quickly, make it easy to maintain over time, and easy to scale (the growth).
Or the opposite way. If you build the wrong things, you don’t increase value. Product complexity grows, so the maintenance. If you don’t build the right things, scaling them up doesn’t make sense.
Focus on solutions, not problems
It’s a company’s culture thing to be “outcome-driven”. Unless it comes from the top, it isn’t easy to implement it bottom-up. But there is one practical thing you and your team can do as a first step.
Focus on delivering solutions, not just pointing out possible problems.
During the next refinement session, see what the communication between Product Manager and engineers looks like. Does PM present functionalities, and engineers bombard her with the list of possible edge cases?
If so, you need to fight this dynamic. The intention seems good — point out all possible problems to build a product that serves all customers and is free of bugs. But the rationale is wrong — engineers aren’t there to find gaps in the list of requirements. Engineers are there to partner with Product Manager and Product Designer to find the best solution and then deliver it.
Let’s look at the example from engineers’ day-to-day work.
Let’s say you build file previewer functionality for the mobile app. Requirements say you need to have the functionality to preview PDFs, PNGs, JPGs, and other image formats. There are two ways of approaching it.
Scenario 1 — listing all gaps in requirements
If your team focuses on requirements during the refinement session, you will hear something like:
- “You forgot about iPhone’s HEIF format.”, or
- “What’s the maximum size of the image we can handle?”, or
- “What about all PDF standards? What if PDFs are protected?”, or
- “We need to have IT ALL written down in requirements upfront because if we forget about something, we will need to force our customers to update the app to get support for the new data format.”
Engineers will probably leave the meeting satisfied with the results. In the end, they listed most, if not all, things that can go wrong. They protected a product from failures and improved estimations' predictability. 🦸♂️
In the meantime Product Manager takes all of the feedback, tries to answer as many questions as possible, discuss the rest with the team leader or project’s stakeholders, and comes up with ticket(s) like this:
- Supported formats: PNG, JPG, PDF, HEIC, HEIF, WEBP
- Build an empty preview state and download button for all files above 20MBs
- Build error message “This file not supported” for all other formats
- Build custom error message for PDF files with password
What’s wrong here? Rather than discussing solutions with the entire team, we use their minds only to point out possible failures in the idea. The idea which is not necessarily the best available one at the moment.
What could this session have looked like instead?
Scenario 2 — finding solutions
The task says: the product needs to have the functionality to preview PDFs, PNGs, JPGs, and other image formats (for the sake of simplicity, take it for granted).
Someone from your empowered team, rather than pointing out possible problems, can say:
- “There are plenty of file formats we will have difficulties supporting — password-locked PDFs, system-specific image file formats, etc.” — this is our problem to solve
- “What if we build AWS Lambda Function, which generates a JPG preview for each supported format? And then only a JPG file is presented by a mobile app. Then, whenever a new file format appears, we will make improvements on the backend side, so a few days later, customers will see it working on their mobile devices without updating the app.” — this is the proposed solution.
Of course, this conversation doesn’t end here. There may be some limitations (like a lack of skills within a team or lack of infrastructure), or other ideas worth considering. Or maybe you need to deliver PoC quickly only to start validating a hypothesis.
But the important thing is this — your team needs to be empowered to bring solutions to the table rather than focusing on possible issues and edge cases. I’ve already shared it in previous article. 👇
Your teams know best how this problem can be solved. You know what’s the latest in technology. You attend tech conferences. You play with APIs and open-source projects.
You and your team know what’s possible and what’s not.
Let’s stay in touch
I hope this article is valuable to you. My mission is to help engineering leaders make great ideas happen.
Explore more content on practicalengineering.management.
You will find there practical strategies for effective engineering leadership. Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.
