Restructuring product management teams is challenging: there’s no universal “best practice” or generic org chart, and people issues are the tough ones. We step through two examples of redefining what product folks do…
Industrial hardware and enterprise software are both great business, but have very economics, scorekeeping, and development models. To run a strong software business, we may need to retool some operating processes as well as executive assumptions.
Software is intangible: it doesn’t have weight or size or per-unit manufacturing costs. But if we’re in the software business, we have to assign units and prices that reflect our value to customers. And we should be mapping out pricing strategy before we start development, not the day before product launch.
It’s easy for CEOs to think that they personally are the best-informed people within their companies about what customers need and what markets want. In reality, product and design teams have the time, focus, expertise, and large numbers of non-selling interviews to do more objective validation of product ideas.
Rich Mironov joins Business of Software Conference in Boston on Oct 1-3 for “What To Do About Your Audience’s Real Roadmap Questions.” Other speakers include Jared Spool, Tania Katan, Peldi Guilizzoni, Claire Suellentrop, David Cancel and Bruce McCarthy.
Many infrastructure development teams don’t have a product manager. That forces an architect or senior developer to manage a range of responsibilities they are not best equipped to handle: settling conflicting business priorities; internally “selling” the value of architecture; tying technical decisions to business metrics; making connections between software and end user joy.
Rich Mironov keynoted the ISPMA’s Software Product Summit in Frankfurt, with a talk on “Product Leadership Success: Lessons from Silicon Valley.” Themes were the continuing dominance of software; critical need for product managers to do real market validation; and a focus on paying customers (rather than internal stakeholders).
Your different audiences have different (often opposing) goals and incentives, which means they probably want different product decisions and therefore different roadmaps. You need to understand and anticipate their agendas.
What are the questions that various groups really want to ask, and how does that shape our roadmap conversations?