Strategic product thinking for the scrappy entrepreneur in all of us.
Strategic product thinking for the scrappy entrepreneur in all of us.
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.
Prioritization is hard, and we HOPE that a clear corporate strategy plus well-considered OKRs will get our internal stakeholders to agree on what’s most important: unambiguous #1 and #2 and #3 priorities. That our spreadsheets and analysis will sell everyone on our plan. But that rarely happen…
CEOs may not see their role in systematic product/development problems, and product leaders may not know how to frame their concerns so CEOs can hear them. Can we get past buzzwords to difficult organizational discussions?
When coaching our product teams (and others), it’s important to remember our objective: to build up skills and talent so that we can delegate as much ‘line’ product work as possible. Plenty of leader-level work left for us…
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?
Prioritization is an essential part of product management. We want it to be a mechanical process: pick a metric, estimate ROI for the entire backlog, then do whatever scores highest. But that very rarely works in practice.
VPs of Product and VPs of Engineering need a strong, trusting, collaborative working relationship so that their teams can succeed. What does that look like?
While development (or maker) teams don’t formally report to product management, there are things we can do to get more value out of the team. And some things that we can’t or shouldn’t…
Sometimes we struggle to communicate important concepts that others don’t seem to get. So we have to try different approaches. Here’s a short post on framing the “shifting priorities” problem in non-technical terms.
After years of struggle, I’m advising all of my clients and product leader coachees to stop using the term “MVP”. Not to stop doing validation, discovery, prototyping or experiments they may associate that that acronym, but to remove the label from all of their docs and presentations and talks. To delete the letters MVP from roadmaps and product charters…
