Having identified “Three-Market-Forces” that highlight an opportunity, you can use the “Big Idea” format to articulate your new product development concept.
Continue reading
Tag Archives: product development
Strong products are backed by “Three-market-forces”
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
35 person-years worth of prototype is a fantastic spec
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
Solution Convergence: Marrying Business, User Experience and Technical Input
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
Build it Twice then Build it again – the 3rd Version Will be Great
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
How to Manage a Vague or Dynamic Product Backlog
In response to my request for questions along the lines of what do I do when … ? Jo asked:
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:
- Normally vague/dynamic
- Completely vague
- Massively dynamic
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
Journalism Portal: My Lean Startup in the BBC
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
Opportunity Assessment – 10 Questions to Evaluate Proposed Features and Projects
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
Reinforcing Success in Products and Projects
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.
Wikipedia: Reinforcing Success
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
Requirements: State the Problem not the Solution
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