Before we start crunching business case numbers, we should think about the underlying money story: who it’s for, how it generates money, and what similar money stories we are considering.
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)?
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.
Visual notes from Rich’s keynotes at Pitney Bowes Product Management Summit. Talks were on “Common SAAS Pitfalls, and How to Avoid Them” and “Building Better Business Cases.”
This interactive workshop with Rich Mironov will help product managers improve their understanding and skills for working with stakeholders, cross-functional teams, executives, and customers. We will frame the main challenges forproduct managers, then look at specific tools/techniques to drive decisions/strategies.
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?
The revenue side of the house often believes that incremental budgets – or major deals – all that it takes to add new items at the top of the development queue. Like ordering a custom-built sandwich at the deli counter…
As data-driven product managers, we’d like to pretend that incoming technical requests are simply transactional. In the real world, though, real people and real agendas are involved. And that means there’s a personal and political context to consider when prioritizing demands on our already-overloaded development organization.
In many conversations over the last few months, I’ve see executive teams grappling with the positive effects of agile software development on their non-development processes and organizations. If you’re a VP of Marketing or Sales or Finance or Operations or Support at an agile software company, or one that is becoming more agile, improvements in how we build software will be shaping how you think about the software business and non-engineering departments. Here’s a short list of items that you need to consider in the face of increasing agility.