Solving Problems vs. Building Products
The communication of your vision determines the execution.
Both startups and enterprises utilize product teams to divide work and allow a team to focus on a specific product, or a specific feature of a product. The team’s focus could be
How do we grow our product?
What features should we add?
What is our product roadmap?
This focus on the product could limit your team’s potential. Yes, focusing too much on your product team’s product can be detrimental.
During a recent session with my team, I caught myself repeating that the software engineers should be focused on building the best solution, regardless of the application / database / API that we own. I did not want us to focus on the best way to use our product, I wanted us to focus on building a solution to the problem in front of us.
The interaction between product managers and software engineers varies by team, but one of the worst things a product manager can do is put guard rails on the software engineers. That is not the job of the product manager. Your team’s tech stack, resources, priorities, the skills can provide guard rails, but the product manager should not.
What does this mean?
There are two key areas where a product manager can (unintentionally) provide guard rails to the team and limit the team’s potential:
Introduction of the requirement
Developing a solution
Introduction of the New Product
Depending on your team norms, this stage could go by a few different names
Discovery & Framing
Inception
Change Request
Product Requirement Request
“The email from the boss”
Although made in jest, many product requirements do come from someone at a high level who wants something added, for a variety of possible reasons.
But overall, the introduction of the product or new feature is a stage where you can’t get lazy. The product manager’s role is to empower the software engineers so that they can create and build elegant solutions.
There are common misconceptions about the idea of thin slicing. One is that we break down problems into very small sub-problems, and we solve for it. If a product team existed in a silo, then that is fine. However, what happens when a product team is tasked with building a product, without knowing the full reason why?
An example I like to use - mainly because it annoys me so much - is internal communication. A product team can be created to solve collaboration problems in an organization. And this highly effective team starts building features on automatic scheduling, syncing backlogs across teams, creating applications that allow for easy management approvals etc. This team is focused on improving collaboration.
However, even if this team is pushing out excellent metrics with consistent velocity, that doesn’t mean the team is successful. Success is not easy to measure, even though we try by quantifying everything we can to produce metrics, charts, and scores. This product team may have created excellent products that solve real problems, but a real problem does not mean the right problem.
In this example - which I created based off of reading the book “Working Backwards” by Colin Bryar and Bill Carr, the product manager should have explored why the organization felt the need to improve collaboration. This part is tricky and ambiguous. Of course, you can perform research that shows that teams are slowed down by dependencies and have trouble knowing other team’s statuses, and learn that teams are unable to figure out who to meet with to get the data access they require / where the data is. All of this tells you that your team is solving a real problem that your customers (other employees) want solved.
Don’t Filter Information
Continuing with this, a product manager could introduce the problem in two different ways:
“Let’s brainstorm solutions to improve the organization’s collaboration.”
“Let’s explore why we think we need better collaboration.”
The first approach gets you the results shown above.
But the second approach opens up more possibilities. Everyone loves collaboration right? Going off the example from “Working Backwards”:
“Why do we need better collaboration?”
“Because we need to manage dependencies.”
“Why do we need to manage dependencies?”
“Because our teams need to work together to launch products.”
“Why do they need to work together?”
“Because teams have access to different data sources and different applications.”
“Why is access not available to product teams?”
“Because…”
This is the line of thinking a product manager should strive to create.
Difficulty of collaboration is a very real problem for many organizations. By focusing on “building products”, your team will build collaboration tools and measure the success of these tools.
But by focusing the product team on “owning” a problem, the team is empowered to create more innovative solutions. This approach leads to a product team focused on improving access to data sources, creating a microservice approach to feed applications, and removing the need to have cross-department dependencies. The same problem can lead to two vastly different roadmaps depending on how the product manager phrases the problem.
Developing a Solution
The other phase where guard rails shouldn’t be added by PMs is during solutioning. Technical product managers may struggle with this more so than product managers that don’t have a coding background. I have to be careful that my team doesn’t take my work from framing and see it as a solution.
When working in ambiguous or greenfield areas, it can be hard to visualize solutions. Ideally, the product manager provides enough direction to get a minimum viable product (MVP) created quickly to force clarity for the team. But sometimes, “provide enough direction” is a complicated endeavor which could backfire.
What you do want:
Present the problem your team is solving
Agreement on the deliverable*
The software engineers to lead the design of the technical features and overall solution
*Deliverable means the value deliverable, not a product deliverable.
What you don’t want:
A product idea brought to the team
Agreement that the product will solve the problem
Software engineers to determine how to build the product provided.
In practice, the design and the “what” of a solution comes from the software engineers. The goal of the product manager is to get problems to the software engineers for them to solve, and help ensure that they have what they need to validate, build, test, and deploy.
An overly simple way to implement this idea is to bring in your software engineers earlier. Don’t wait until you have a solution designed in your head before you meet with the engineers, get them involved early so they understand the problem and the customer needs before they are introduced to the product manager or other’s (especially those above them in the org chart) ideas.
This prevents the creation of guard rails to your team. Sometimes, ambiguous situations prevents solutioning from starting, for a variety of reasons - including the inability to visualize the problem. In these situations, I like to provide a “prove it” solution to the team to show them what a possible solution could look like. In the office, I call these “ugly solutions”. To ensure this doesn’t limit my team, I only do it when the software engineers aren’t able to begin solutioning, and I will ‘challenge’ the team to create something better - as these “prove it” solutions are often not scalable nor efficient.
Start with the Best Solution, then work your way to the Best Feasible Solution
When solutioning, give the engineers freedom to create. In the first solutioning session / early in the process, don’t worry about costs, technical stacks, or most importantly, the current products your team owns.
This makes the thought process of building products vs. solving problems more evident. Allow the team to be creative and entrepreneurial and focus on the problem they are solving. After this, start researching the feasibility and adding constraints. But don’t be immediately dismissive either - don’t turn down a home run product because you have to buy a new tool or meet with the legal team.
Once you get a best feasible solution designed, start the agile process of building MVPs and iterate based on the new information the team gathers. The best feasible solution is a living idea, that is easily changed when new information is received.
Solving Problems vs. Building Products
As a product manager, the goal is to empower and enable the team. Allow engineers to be creative and innovative, and don’t provide guard rails that limit them.
What you don’t want is a bunch of engineers being told exactly what to do and how to solve their user stories. Engineers are creatives and problem solvers. If your team doesn’t utilize them, they will become disengaged. If your team doesn’t utilize their creativity and ingenuity, your team will not be a high performing team, regardless of what your metrics say.