It’s funny, but potentially unproductive, when stakeholders filter down the story or requirements before approaching the Product team – their own triage of sorts.
Funny because it’s almost as if they were doing the PM’s job (undoubtedly a blissful position for some PMs!).
Unproductive because if the PM doesn’t ask further, the watered-down feature may not solve the real problem, and may not even be salvageable.
It’s also not a good sign if the stakeholders are watering down out of fear – because they’re worried it will take forever to bring out the feature, they cut down the spec or story. Maybe it’s subconscious trust issues – IT is too slow/doesn’t really help us so we’ll just make do, or vice versa; stakeholders don’t understand so let’s just keep communication more opaque and not bother asking…
Yes, if it’s too big a request, it can’t be done all at once and has to be broken down. But if the PM and Development team doesn’t have a fuller picture, the outcome could be worse. It’s like repairing a shoe with masking tape instead of good glue – a temporary fix that costs money and doesn’t really solve the long-term problem.
Anyhow, the lesson learnt is to ask the deeper whys (this seems to be a recurring theme in my posts, I guess new habits are harder to pick up). I found this article by Intercomm.io insightful. To sum it up, dig through the layers of why (a low level why isn’t hard to get but may not yield the right insight), and do it pleasantly.
Case in point recently: I got a request to add some timestamps in the DB for tracking purposes. I asked why, and after understanding a first layer pointed out some possible fail points of the solution and proposed we log cumulative time instead. Stakeholder agrees, I write the high level specs and get the green light, so we prioritise it. The next day, stakeholder returns, having found out something deeper on how the real requestor envisions the data being used, and we both dig more and find out the original spec just might not cut it.
Admittedly, it is part of the Agile process anyway – acknowledging that information is never complete at the beginning, understanding that stakeholders/requestors will never really know if something works until they try it. The route to the best solution isn’t always clear, and there will be the need to do these quick and dirty or incomplete solutions.
Phew, I still have a long way to go.
I jumped from Product Marketing to Product Management at Zalora recently. These posts represent a journal of my learnings and reflections – you can keep track of my journey by joining the mailing list here.