Many companies have replatforming efforts underway. This is an essential part of the software product business, but fraught with poor assumptions and lack of experience/understanding. I’ve seen the majority of these replatforming and reimplementation efforts fail…
Product Management Helps Us Build the RIGHT Things:
Strong product managers spent up to half of their time talking directly with customers, buyers, and partners. And the other half of their time with their teams: framing problems, collaborating on solutions, translating features into benefits and vice versa. Making sure that we’re building the RIGHT things as validated directly by users and buyers so that we deliver customer-defined value as well as increased velocity. That’s different from the narrow scrum definition of product owner, which is mostly internal-facing.
We know that external customers must recognize a problem before they consider buying our solution. But I often see product managers / product leaders forget this when dealing with internal stakeholders and executives. We push for product-side practices and processes without clearly framing the underlying problems. I think of this as ‘selling philosophy.’
Rachel Obstler, VP Product at Heap, invited me in for a two-part conversation on her Product Therapy podcast. This is the second portion, where we talked about: Can we schedule innovation? No, but start with hypotheses… Insights are in the heads of our users: we have to discover things that they don’t already know What
Steve Divitkos’ In The Trenches podcast series is for entrepreneurs and CEOs running small/medium-sized businesses. I joined him for an episode about the importance of product management at the executive level.
Rachel Obstler, VP Product at Heap, invited me in for a two-part conversation on her Product Therapy podcast. This is the first portion about why finding insights is so painful – and what you can do about it. We had a free-wheeling chat about common analytics pain points for product teams and how digital experience
Company leaders who aren’t steeped in how software is designed and built can apply less-than-useful analogies for how software products are built. These analogies tend to highlight predictability, scheduling and cost management… but may not be that useful. This post unpacks a few of them.
Everyone wants innovation, especially if we can plan and schedule into each sprint.
But innovation is uncertain. Can we shift the discussion to planning and scheduling and funding of discovery that can (often) lead to innovation?