There are no generic or universal KPIs, since every business has unique aspects. So if we want KPIs for a B2B/enterprise company, where would we start? And how do we avoid committing to improvements in metrics/KPIs before understanding our current scores (or situation)?
As product folks, we should be responsible for reasonably anticipating misuses of our products, as well as harm that flows from fundamental product/economic goals. It’s not clear how we step up to this, though.
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.