The other day I read this piece by Joseph Puopolo a Canadian blogger and VP Marketing & Business Development at StickerYou, with extensive experience in marketing and product management. In his latest blog post Puopolo shares his thoughts about “5 Things a Good Product Manager Should Think About”. Having just started a new product manager role with 7digital I thought there was value in going over Puopolo’s suggestions and see if and how I would apply them.
In short, these are Joseph Puopolo’s 5 things for products managers to consider:
- Minimal Viable Product thinking can be a trap – I agree with Puopolo that there’s a risk of being so focused on minimum marketable features (i.e. quick turnaround times in getting a product out there followed by ongoing iterations) that businesses end up releasing inferior quality products, with discontented customers as a result. At the same time though, I do believe it’s important to stimulate an iterative approach whereby designers and developers focus on getting ‘baseline’ functionality right, release it and then continue building on this.
- Keep an eye on what really matters – Puopolo argues that there are 3 key areas product managers should always be focused on in order to avoid ending up with what I’d call a “feature soup”. (a) Will the feature in question help to make money? – It sound likes such an obvious question but how often are we tempted to lose sight of this when we comes across a cool sounding bit of functionality or when a stakeholder comes to us with a requirement. (b) Will it improve the user experience? – I agree. I’m not an UX expert so my UX principles are therefore very simple: keep it simple and intuitive. I’ve learned to ask myself questions like “What are they key features that the user is expecting?” “Will people abandon our application if we make the feature too extensive or too complicated?” (c) Will it improve efficiency and scalability? – Yes, especially if you’re at a startup with a limited budget, it’s import to always question whether a feature will improve efficiency and whether it’s (re)usable for other applications or other parts in the business. (d) Will it have an impact on existing (or future) functionality? – This is a question which isn’t part of Puopolo’s suggestions but which I believe does need to be taken into account, considering how a planned feature is likely to impact on existing or other future functionality. (e) Does it fit in within with the business vision/strategy? – Not listed by Puopolo but working out if and how a specific feature ties in with the overall business strategy is in my view an important task of a product manager. (f) Will it change customer behaviour? – Before a product is released or shipped out, please do test it. Especially as a product manager (who acts as the voice of the end-consumer) I think it’s important to do as much testing as possible prior to releasing. For instance, Eric Ries suggest to do A/B testing whilst developing a product to see how consumers respond to a new feature.
- Create a vision for the product – Couldn’t agree more with Puopolo on this one! Creating a product vision doesn’t mean that that this needs to be an extremely painful or onerous exercise. I do feel, however, that it’s very important to have a long(er) term vision in place to check new features against. No one is a true clairvoyant (apart from Steve Jobs perhaps) but I think it’s nevertheless important to have a clear vision in place for the product. Answers to questions like “What do we ultimately want this product to be?” “Which customer needs do we aim to address?” “What would a follow-up product or iteration look like?” do by no means need to be set in stone, but serve as a good safeguard to ensure that we’re developing the right product.
- Beware of the “Frankenstein” product – This point by Puopolo mostly has to do with the UX aspect of creating and managing a product. It ties in with Puopolo’s previous recommendation about having a product vision. I guess we’ve all been tempted at times to just throw in a button or create a workaround to satisfy a stakeholder request or to solve an ad-hoc problem. The risk of this approach is that you ultimately end up with what Puopolo calls a “Frankenstein” product, a patched-up product with a non-intuitive UX flow.
- Know your customer, and then start to segment – I’ve found that this can sometimes be harder than it sounds; “Who is your (end) customer?” “Is it the consumer or your advertisers?” I agree with Puopolo that it’s very difficult to create a one size fits all approach. I guess as a product manager you have to ask the question whether to serve all people with a ‘compromise’ version of the product or to split the product into different versions to meet the different needs of the various target audiences.
Main learning point: Joseph Puopolo’s ‘5 things’ are in my view right on the money. Whilst most of the key things to be aware of are not rocket science, I guess that as product managers we at times are all guilty of ignoring one or more of the considerations that Puopolo raises. His thoughts therefore act as a very useful reminder and definitely something to refer back to.
Related links for further learning:
4 responses to “Always good to learn about product management – 5 things to think about”
The last 3 points, especially #5 (well, in a way), can be applied to project management. Knowing your customer’s business is key to gathering excellent requirements.
[…] evolve and crystallise sooner than you think! I learnt from product people like Andrew Levy and Joseph Puopolo that a product vision will almost adjust itself as you launch a product and you learn about how […]
As a product manager, how do you explain what you do to non-technical people?…
Like some of the others above, I sometimes struggle to explain what it is that I do. I typically start off by by mentioning the kinds of products I look after, followed by explaining one or more of the following things: * Knowing my customers and under…
[…] should be (I’ve written about both iterative product development and the risks of releasing too early too often before). This is is then followed by development, testing and deploying the highest priority/value […]