The good news is that you have an engineering team that is excited about the product & generating ideas. That’s huge. Over the long term, this will make your product more successful....so long as you can channel that excitement towards features that are also exciting to customers.
Your goal is to help your team fall in love with problems, not solutions. I’ve seen over and over again how this simple mindset shift can be a game changer for more user focused decision making.
Here are some approaches to consider:
-
Expose your team to users - have engineers shadow user research sessions, share clips and quotes, or simply talk about your customers constantly. Bake user feedback into the development process if it isn’t there already. I’ve found that teams get most inspired when we ground their work on real humans. Use this to your advantage.
-
Tweak your process with one pagers & “problem kick offs.” For every non-trivial project you take on, write a simple, one page description of the people problem, hypothesis, success criteria, and “skeleton of a solution.” By skeleton I mean, just enough to start thinking about solutions: e.g. "the ability upload a pin to a board" vs. "an upload button on the profile." Schedule a kick off to discuss and debate the problem, refine your hypothesis, brainstorm potential solutions - even before getting into requirements.
-
Perfect your problem statement. Below are some best practices for writing problem statements. You may even encourage your engineering team to write these for their ideas! Here's what makes for a good problem statement:
- Is ONE sentence
- Gets as close to the actual human behavior as possible. Avoid sayings like “the industry is changing” or “our systems are disconnected” those are just facts not problems in and of themselves.
-
Does not hint at a solution. Example of hinting at a solution: “We don’t have a common place for users to come…”
- Is as specific as possible. Example: “drive efficiency” often isn’t specific enough - what does that mean exactly?
- Is written in plain & simple language. “Project managers don’t have data tracking mechanisms built into their current workflows” => “Project managers don’t know what’s on track and what isn’t”
- Includes WHO it’s a problem for (preferably a human being)
- Is meaningful - describes the impact/negative outcome