The start of 2017 seems like a good time to get into the swing of things with a weekly newsletter.
Don’t consider it a new year’s resolution – that increases the chance that I won’t keep it up.
Think of it instead as my way of getting more done by doing less. In this case cutting out all of those non essential activities so that I can focus on the truly important things – providing you with great resources about business analysis and product management.
Each week I’ll send out a carefully curated set of resources targeted on helping your IT organization get more done by doing less.
The resources are organized under one of five categories:
- Outcome over Output – Define and measure progress and success based on the outcomes you deliver, not the outputs you produce.
- Shared Understanding – Building and maintaining clarity around the need you are trying to satisfy
- Decision Making – Make effective decisions to keep the focus in the right place.
- Roles and Organizations – Keep straight the differences between business analysis, product management and other related roles
- New from KBP.Media – The latest post, often describing a useful technique from our blog.
I’ve done the searching across the internets so you don’t have to. Hopefully you find it useful, and if you think someone else will find this useful, please pass it along.
Here’s to 2017 and a new year of learning and effectiveness.
Kent J. McDonald
Outcome over Output
By Chris Matts, The IT Risk Manager
For the past year or so, I’ve been thinking about metrics. When measuring the effectiveness of your development investment process, I’ve come to the conclusion that you need three outcome metrics… A “quality metric, a “value” metric and a “time to value” metric. You need the three metrics because any two can be gamed. For example, you can maintain high quality and a low time to value by releasing software that delivers no value.
Quality metrics are fairly straight forward… number of bugs released is a fairly standard metric. Value metrics are fairly easy to define but sometimes harder to measure… e.g. profit, revenue, number of customers. The tricky metric is the “time to value”.
By Marty Cagan, Silicon Valley Product Group
I find that many teams, especially those new to modern product techniques, are looking for a structured introduction to modern product discovery. In this article, I’d like to describe the concept of a discovery sprint, and also introduce you to a new book that goes into depth on this technique.
You may have heard this everywhere, but, here it goes again, you will need to have the ability to say “no” to anyone, your customer, your team member, and even your CEO. Not all features have a place on the roadmap, and not everyone has the right data or information to decide when to include something, when to reduce something and when to leave it out altogether. This is why we need product managers.
Roles and Organizations
By Andrew Dickenson, Product Focus
Internal product managers come up against unique obstacles and dilemmas. The challenge is serving internal customers rather than selling to external customers.If you’re stuck in your role as an internal product manager we’ve outlined 6 ways to break free.The post Are you an internal product manager stuck in a box? appeared first on Product Focus.
New From KBP.Media
The risk management game is a collaborative way for your team to identify risks that they face, categorize those risks based on impact and probability, and determine which risks to address first.