So an engineering manager from a partner company mentioned to me he likes the way I think about product – end-to-end. He said he wondered if I could share my philosophy with him and his team at some point. So I thought I’d give it a go here first, to hear your feedback and thoughts as well.
I don’t know how to convey all the experience behind these building blocks, in just a few sentences, so take this short and stacked blog post for what it is. The key point to remember is that your product stretches beyond the code you deliver.
- If your product is hard to market, work better with marketing and customers to define the pain points and the right key messages that resonates. Create a focus group to distill what the real perceived value is.
- If your product is hard to debug for engineering, expect it to be even harder for support, field, and end consumers – focus on modularizing the codebase, transparency, and better insight tools
- If your product is already causing high support loads, spend a few sprints focusing in on instability areas (increase test development) or ease of use (do user studies, customer interviews, improve docs and help), or increase tooling and visibility into whatever area drives the most support tickets to get better data insight into what the root causes may be
- If your product is hard to integrate with, work on better APIs for partners, and reliable backwards compatibility designs. Again, why not create a focus group?
- If your product is hard to sell, work on better defined use cases and more reference customers, or look into repackaging – maybe you got it wrong what the customer needs?
- If your product is not rapidly adopted, do end-to-end usability studies, spend more investments in documentation, hire a UX designer, or create adpot-a-customer programs and let your engineers work closely with the customers using the product to figure out the UX gaps.
Points above are there to show a good product manager do not only focus on end customers, but every stakeholder touching the product lifecycle that affects the product’s long term success. And secondly, that the product stretches across many teams and organizations, and it is your job as a good product manager to also keep these teams in mind, as customers and stakeholders, in your continuous product feature prioritization process.
Also, did you know that paranoia is a positive thing to suffer from as a product manager? Expect the best, plan for the worst. Always always always have a plan B, C, D… And never never never commit, unless you are explicitly forced to by your CEO. Plans always change. Engineers always hit unknowns. The worst you can do is commit to a date and then disappoint your customer who plans around that date. Margin in any timeline will always be needed.