I’ve been doing a lot of thinking lately. Most of it while in process either executing on tasks with which I am quite familiar, or performing new ones that I’ve only either done a few times before, or not at all.
The funny thing is, I’ve been immersed in Product Management for so long in my own mind, that even when doing something either a) a little differently based on a scenario or b) doing something for the first time in my career, it all feels quite natural.
It’s funny – when I first started out, much of my concern lied with things like, “what does this mean” and “how do I do that?” type stuff. But now, with all the fundamentals in place, it’s getting really exciting to see things play out, and really drive them forward.
One of the best examples of this is introducing stakeholder’s into the feedback process. We’ve been working very diligently on a set of product development projects. They are really fun, and frankly, taxing. Creating a full product from scratch is no easy task, and to do it on short timelines makes it even more difficult.
But, we are prevailing.
Now, getting ready to go live (different then a full-scale launch), it’s time to start circling back in and revving up the feedback cycles & loops for the product itself. And, I’ve been very pleased. While I can’t lay claim to being a complete expert in the process and procedures of gathering feedback, it’s one of those things that I do know how to do.
When you have a product you are proud of, looks sexy, works well, and isn’t 100% perfect (because they never are), it’s so fantastic to hear and see people interact with the thing and listen to what they have to say about it. I always remember reading somewhere, and I can’t express how true this is, that one of the top word’s in a product manager’s vocabulary is “why.”
Getting feedback from someone that says, “gee, your registration sucks” is only 1/2 the feedback. To know why they think it sucks is where you get into extracting value from feedback gathering. Because once you do that, you can leverage the information along with all of your other data, determine if there is in fact a problem with something (in this example, a registration process) and construct a requirement that suitably solves the pain.
Very nice & tidy. It doesn’t have to be long, drawn-out hours-long presentations. The tough part is approaching key people that will provide critical insights before you have a base of users that are really willing to give you a piece of their mind, because they are shelling out hard-earned money for the product.
Listen (no, really listen) to what folks have to say. When criticism or negatives come out, that’s what you want. Don’t jump to the defense of the product, because that just turns in to you jumping to your own defense.
Like anything, practice makes perfect, but before rolling out for the first time, really make sure that all key players involved are fully behind your choices and decisions as a product manager. They won’t agree 100% of time, but where’s the fun in that?
So long as you have the data to justify and back-up your calls while in the thick of the product development cycle will prove that you really do know what you’re doing, and quite honestly their instinct is misplaced & goes against the greater good.
Comments on this entry are closed.