,
8 tweets,
1 min read
Read on Twitter
One of the main recurring problems I see with digital teams is being given solutions rather than problems. “Build this feature”, “build that feature.” While this is understandable it inevitable relegated them to deliver teams.
I guess one attempt to solve this has been the writing of user stories. I imagine the home is, by framing everything as a user need rather than a solution, you’ll escapee the build trap.
Sadly what PMs usually end up doing in this situation is becoming translators. “This stakeholder has asked for this feature, so I’m going to translate that feature into the language of user stories.”
That way, they can maintain the pretence that they are being agile and user centred, when at the same time committing to deliver exactly what their stakeholder has asked for.
One of the reasons for this is that 12-18 month roadmaps tend to focus on features. If the features have already been decided in advance, there’s no point pretending you’re focusing on user/customer needs.
As a result I’d love to see more roadmaps focussing in the problems you think need to be solved, rather than the solutions you think are the right ones to solve them.
The big challenge is that it’s really fun for executives to play product by coming up with solutions, even if they are the obvious solution and there may be better alternatives out there.
Also, executives are used to taking the role of problem solver rather than problem finder. So if you present execs woth a bunch of problems, what do you expect other than a bunch of potential solutions.
