Skip to main content

I read this story on Medium by Mithil Srivastav some weeks ago, and although I definitely don’t agree with point number 4, I believe it’s an interesting piece. I especially like the parts about being data-driven:

You need to get as much data as you can before taking a decision. Be paranoid with data. Be the devil’s advocate and ask yourself questions “Why ”, if you don’t have a data backing the answer, keep searching.

Too many times have I seen projects and organization trapped in the “feature factory,” where the only thing that matters is “delivery” (oh how much I hate that word in product development and IT) and the release is seen as the end of something – instead of the beginning.

What are your thoughts on this?

@Henrik Ståhl -

I couldn’t access the article as it brings me to a “sign up for Medium” type page, but based on your review here are my thoughts.

Just like planning, there’s a fine balance between acting on insufficient data and holding out till you have complete information. And sometimes it is not about the quantity of data but rather the quality of the data you gather.

The problem you’ve raised relates to losing the sight of “why” we do things. It is too easy for leaders (and teams) to focus on things which are easy to measure like release dates or number of features rather than those which are harder to count but are more valuable.

Kiron 

@Kiron Bondale Oh no! I accidentally pasted the wrong link in my original post… 🤦‍♀️ Here's the correct one:

https://bootcamp.uxdesign.cc/sorry-but-you-are-not-a-product-manager-5cd36877c426

I totally agree about the fine balance between acting on insufficient data and holding out until you have complete information. Spending months and months just analyzing stuff, believing you can ever get the full picture before actually doing something (you can't) just drives me mad. I even wrote about it recently:

https://medium.com/codex/move-fast-and-break-things-is-sadly-misunderstood-f6684a55661a

The Why is so important in product development, it can't be overstated.

This was an interesting read, thanks for sharing!

 

My take on point 4 is more that a successful PM needs to be able to turn the actionable recommendations they deduce from data and insights into something workable for the design team. In my former life I’ve definitely struggled as PM also attempting to create full-on wireframes, even if low fidelity, so I agree on that point. Now I just napkin sketch for my team if I don’t have time to wire it out in Miro, which I think is more than sufficient. So I agree with the sentiment in general but not necessarily the way it was written in this article. 

 

Something I think the writer could’ve added here was about having a steadfast eye on the audience. A lot of these points ladder up to this notion, but he failed to spell it outright. Not only do you need to ask why, understand the problem, find data, and set KPIs and understand how to track towards them - successful PMs all continuously put themselves in the mindset of their end user and double down on that no matter the conversation.

 

@Michelle Murphy That’s a really good point. In the article, it sounded a lot like the author believes a PM should make wireframes and hand them over to the UX/UI designers to refine. Those sort of sequential processes, with “requirements” and “demands” and “handovers,” is really not my cup of tea. But when you put it like that, I now see another sentiment in what he writes. I actually do a lot of “wireframing” in Miro to visualize thoughts and ideas together with my team, but I’ve never really thought of them as wireframes. More like doodles and dabbles to make discussions tangible. :smile:

I couldn’t agree more about PMs continuously putting themselves in the mindset of their users! It reminds me of some retros I did on that topic when I was working with a team developing an in-house built headless CMS for news sites (this was before Contentful ruled the headless world). In one of the retros, I divided the team into two groups with designated roles taken from the newsroom; one news editor (sort of coordinator), some editors, some reporters. And I had prepared a scenario in advance. Like, “X happened this morning. Publish one of the short newswire articles, then enrich it with images, graphics, fact boxes etc, and update the text with more information.” It was such a fun retro – and the team learned a lot about our users, just by roleplaying them for an hour! :slight_smile:

Hehe yeah I can’t speak for the author, but that’s always been my approach to Product!

 

Love your retro idea, we’re doing something similar tomorrow but for user journey mapping. I wonder if there are good Miro boards to assist with this :thinking:

@Michelle Murphy Ooh, nice! There are a few user story map templates in Miro. Not sure if there's one tailored for a retro though 🤔

Thank you Henrik for highlighting the concern with point 4. I am the. author and would love to respond to point 4. Here what I meant is that Product Managers should have a sense of wireframes and create a low fidelity wireframe himself to get more clarity, Designers should refer to the wireframes only as a reference and not as a guideline.

Reply


Terms & Conditions