Ask a Product Manager Question
I finally found some time to put my thoughts down on paper from a question Jeff Lash sent my way regarding how to gather data in an organization (either B2B or B2C) that may not want or support PMs talking directly to prospects or customers.
Crazy idea, I know. Believe me, it happens quite a bit.
So, here it is: Can a product manager get feedback without talking to customers?
Listening Labs
Not sure how many of you out there have been a part of usability studies or testing. My personal opinion is that “studies” put people in contrived situations and expect them to yield real-world data about how they are interacting with products.
This research is inherently faulty. Why? Namely because when asked, the natural response is for people to tell a researcher (or “expert”) what they think they want to hear.
Funny enough, Harry Beckwith covers this very, very well in his book The Invisible Touch.
I just watched one of Robert Scoble’s early interviews at his new FastCompany.tv gig with Mahalo founder Jason Calacanis. It’s not secret I’m a big Jason fan, and I think the Mahalo product is outstanding; in fact, it has replaced Google as my homepage.
The whole interview (parts 1 and 2) are really worth watching. However, about 13 minutes in to the first segment, they interview Mahalo’s Director of User Experience. He talks specifically about what i started this post discussing. His insights about what Mahalo does are fascinating - check it out:
To follow this up, Eric has created a Mahalo page with his insights and information about user testing. This is fascinating stuff, and I hope it can bring some additional depth to your product development process in the future.
Agile Risks
It’s easy to get taken with the simplicity of agile. Less requirements to write, less documentation, less time planning - but it all pans out in the end. I find that once you are in the thick of it, there are intricacies that can really bite you in the ass if they don’t have the proper attention paid to them.
Let me provide an example that has to do with requirements - writing them, providing them to development, and just their overall management.
If you write a one-line requirement, develop your workflows, and then your wireframes and send it on over to development, is there a risk they won’t get it? Um, yes. For sure.
Now, on the flip side, could you spend a lot more time writing those requirements, break out each permutation and case, and then send it on to development and still have them make incorrect assumptions? Yep - probably much less of chance, seeing as the requirement would box the developer into exactly what needs to be executed, but there is still a chance.
But, will it take you much longer to write that requirement? Yes. Will there be more documentation produced as a result? Yes. Will people talk more, or read more? Read more. Is that bad? In my book, yes it is folks.
See, you want people talking as much as possible. Communication. Remember that thing people did before e-mail and telephone? They actually talked to one another - face-to-face. Why people don’t do this as much now is left up to a myriad of reasons. However, the “agile” style of simple requirements (i.e., capture the damn idea and what it is supposed to do, design it so you don’t have developers opening up Photoshop and churning out graphics, and write all the necessary associated copy, etc.) will intentionally drive more and more communication.
The product manager should be ahead of the release curve. We do one release per month and I’m already planning May. This is highly ideal (while not always possible in every scenario) because I have a ton more bandwidth to provide the necessary attention to, and answer the questions about, how certain requirements are to work.
Now, developers of course need to know when to ask the questions. Because this style of requirements leave a lot more flexibility (by design), they need to know it’s OK to say, “alright, product flunky, I don’t get it. Why is it supposed to work this way?” To which I would reply, “for reasons X, Y, Z” or, “um, I dunno. Good call - you got me. Let’s make a change.”
Now, how does this relate to risk? Well, of course, this method leaves you open to having development mis-intepret the requirements, not ask about them because they believe to understand them and they are seemingly clear, and they get implemented wrong.
This is bad, but hey - agile is all about iterations. Sure, expect to get possibly lambasted for not getting something out the door because the requirements weren’t understood (PMs, I’m talking to you - a release is your responsibility), but at the end of the day, it’s one of the key agile risks.
You could toil away in your office, spend three weeks writing requirements for a single feature (been there, done that) and then always be “catching up” or “not getting stuff done on time due to having a lack of time to do it.” Or, just document what it’s supposed to do and trust your developers (because they are really super smart people) to interpret and understand, and know when to ask questions.
Then, expect you’ll have some good conversations, and possibly some healthy conflicts, over what something is supposed to do. And that, my dear friends, means the product is going to be a lot better at the end of the day.
