Bring Problems not Solutions
Lessons
Avoid prescribing solutions to your engineering team
Push them to get comfortable with ambiguity
Stay committed to the first two in the face of short-term pressures
If you’re a Product Manager (PM), you’ll probably resonate with the unrelenting urge to solve problems. I’d even venture to suggest that if you don’t have that urge, Product Management probably isn’t a great fit for you. You may even have the old adage “bring me solutions, not problems” drilled into your head by a former manager. What I see this manifest in is PMs who write prescriptive requirements and prescribed solutions, which in turn creates order-takers of your engineers, which then creates tension between the PM and their team when what’s built isn’t exactly what the PM had envisioned (nevermind there may have been technical constraints, varying interpretations of the requirements, etc.). The problem with this model is not the engineering team - it’s the mindset of the PM.
First off, the engineering team (hopefully) doesn’t report to you, so they’re under no obligation to follow your orders, nor should you want them to. Second and more importantly, if your engineers are simply order-takers you are severely underutilizing their potential, and as a PM one of your chief responsibilities is to maximize the product’s potential which is directly tied to the utilization of the team’s potential. Another way to think about it is that when the PM prescribes a solution to the team, success relies on the creativity and intelligence of that single individual, instead of leveraging the collective creativity and intelligence of the group.
The alternative to this is a healthy, collaborative dynamic between the PM and the engineering team that leverages a 1+1=3 model of intelligence and creativity, leading to faster and more powerful solutions to problems. I’ll give you an example:
I was the PM for a customer portal that had a live-chat tool integrated into it. At the time the tool was very basic - start a chat, input your problem, get connected to an agent, end chat. The feature I requested of the team was to leverage a bot that the live-chat vendor offered out of the box. I wanted to try to deflect some of the traffic away from the agents, while still solving the issue/question that the customer had. I provided the team with a simple user story, some business context, and asked them to come back with a proof-of-concept (PoC). What I envisioned was a simple question and answer matrix where the bot would present common questions, and when the customer clicked on one, it would provide a pre-written response. That’s all that was offered out of the box. What they built however, was beyond what I knew was possible with this vendor. In just the PoC, not only had they built the simple Q&A matrix, but they had integrated our AI-powered search tool on the backend to scour our knowledge base and have the bot present the most likely solutions to the question based on the customers profile and input if they responded with a question instead of clicking one of the options. It sounds simple now, but again it was far beyond what I thought was possible and it was also atypical for this team; up to that point they had operated as order-takers. So, I thought hard about what went differently that time to cause such an impressive outcome, and I quickly realized that it had been my fault previously for prescribing solutions to them.
So if you've found yourself in the solution-prescribing model, what can you do now? There’s three steps you need to take from here to start helping your team maximize their potential:
Change how you write requirements
Push the team to get comfortable with #1
Be patient and positive with the results
Change how you write requirements
First, if you aren’t writing requirements as user stories, you should be. However, I bet that even if you are using user stories, and especially if the issues above resonated with you, then you’re writing them incorrectly in one nuanced but vital way.
For those who don’t know, a user story is a simple template that helps frame the situation for the team and it’s formatted as “As a [persona/role/type of user], I want [goal/ability], so that I can [outcome]”. For example, “As a new customer, I want my question answered via live chat, so that I don’t have to call in and wait on hold.”
The problem however, is that most PMs use the middle third (“I want…”) to state the feature they want. For example, “As a new customer, I want live chat to start with an FAQ, so that I don’t have to call in and wait on hold”. This statement is too prescriptive, and had I used that version, at best I would’ve gotten exactly what I asked for: a simple FAQ. Thankfully I used the first version, which frames the context as a “new customer” which indicates they’ll have basic questions, but kept the solution generalized to simply “via live chat” which left plenty of room for the team to innovate. This may seem like an overly simplistic change, but I guarantee when you do it that your team will immediately start asking for clarification as to what exactly you want. This is a good indication of their reliance on you’re explicit direction.
If, when you first try this reframing, your team absolutely requires more information, you could add some relevant business context for them. For the live-chat bot, I included a list of our top-10 most common live-chat and phone topics according to our engineers (we didn’t have a way to generate this programmatically at the time). You should certainly also include things like contractual requirements (SLAs, data management/retention, etc.), but short of that, try to push yourself towards less-is-more.
Push the team to get comfortable with #1
The team is almost guaranteed to balk at this the first few times you try it. They may even be frustrated or angry because you’re not giving them enough direction to work with. Though I’m certainly not suggesting you become a roadblock to their success - collaboration is key throughout this whole process - you should be steadfast in not providing them with solutions. They have the gift of a new perspective, and you need to push them to leverage that, get creative, and generate solution ideas and even a PoC. This applies to both big problems and small ones. In fact, small problems are the most tempting to solutionize for them because they usually seem so straightforward. However, if you refrain from solutionizing even in these circumstances, you’ll be surprised at what dots the team connects, potentially solving even bigger problems along with the small one.
Be patient and positive
This could take many at-bats for the team to get the hang of it. You’re applying pressure to shift the culture of a group of people - that’s no easy feat. It’s vital that you stay the course, stay patient, stay positive and allow them to fail, inspect, adapt, fail again, adapt again…and eventually succeed. The first few times they try it, they’re going to be vulnerable, and they’re trusting you and your reaction. Hopefully they knock it out of the park on the first go like my team did for me, but it’s more likely that they come back with an infeasible or imperfect solution and if you grill them for it, you’re violating that trust and it’s going to be even more difficult to get it back the next time.
I’m not suggesting you ship a bad product or feature just to encourage them, but approach the situation collaboratively - show appreciation for the good part(s) of their ideas (there’s always at least one, even if it’s just their hard work), be candid and direct about why the other parts don’t work, and then show excitement for seeing their second iteration.
Like most things, though the three steps sound simple they’re difficult to do consistently, especially in the face of tight budgets, short timelines, and the slew of enhancement requests you’re undoubtedly juggling. However, this is about playing the long game and whenever possible you need to resist allowing the short game to take control and prescribing a solution. If you can execute those three steps consistently I promise you’ll be shocked and impressed by the solutions that begin emerging and how your product begins to shift in positive ways you never would have imagined.