Oren Klaff’s book is on how to “Pitch Anything” however it includes a lot of valuable insight into start ups and new product development. One idea I liked was the “Three-market-forces” pattern. Continue reading →
I once invested 35 person-years worth of effort on prototyping. From my perspective this was time and money well invested. By the end of that time we knew, really knew, what problems our customers were facing and how to solve them. Continue reading →
My product owner was upset when I told her she couldn’t have the widget that she had agreed with the User Experience (UX) Designer. The problem was the design was not technically feasible. To get a great solution to meet the business requirements three parties – business, user experience and technical – must agree on the approach. That negotiation is what I call “Solution Convergence”. Continue reading →
It is not something I want to say to a new client, but even before we touch a line of code, I know it will be the third version of their new product that will be great. The first two versions will serve their purpose but will be at just okay from a user’s perspective. Continue reading →
What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.
In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:
The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.
The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem. Continue reading →
For the last couple of years I’ve been running a lean startup within the BBC. No really, I mean it. It is indeed possible to have a successful lean startup inside a large publicly funded corporate. It is all about your outlook. Continue reading →
You should vet proposed features of a product and, at a higher level, complete projects. A quick and light weight way of doing this is with the 10 questions of the Opportunity Assessment. Continue reading →
A fundamental military axiom is to reinforce success.
Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.
I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager. Continue reading →
We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.
What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders. Continue reading →