Ask someone what they want, and they’ll tell you they want a faster horse. Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.
Category Archives: Requirements gathering
A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.
Continue reading A Prototype is Worth a Thousand Lines of Code
The High Costs of Building the Wrong Product
As product managers, we talk about creating the right solutions with our products. Understanding the very real problems our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.
Other than being “not as good,” how expensive is it to build the wrong product?
Continue reading The High Costs of Building the Wrong Product
Business Goals and Requirements
One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements. His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”
What you call your requirements is less important than how you communicate them.
Continue reading Business Goals and Requirements
Most Engaging Articles of 2009
Engagement – that’s what this whole product management blogging thing is about. Check out what Tyner Blain readers found to be the most engaging articles in 2009.
Continue reading Most Engaging Articles of 2009
Stakeholders in a Barrel
There’s really only one way to travel down a waterfall – in a barrel. A lot of people died this way, but some survived. Software projects have been predominantly waterfall projects since the start of software projects. And stakeholders rode down those projects, basically in a barrel. The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end. Stakeholders in waterfall projects don’t know if they will succeed until the end.
An agile project is dependent upon tight interaction (and feedback) with stakeholders.
If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?
Continue reading Stakeholders in a Barrel
Hidden Business Rule Example
A business process is not just a sequence of steps. A business process is a series of decisions and actions. Some decisions are obvious and can be actively managed. Some decisions are hidden, and until you discover them, you can’t manage or improve them. Here is a real-world example of the discovery of a hidden enterprise decision.
Market Driven Competitive Advantage
Your strategy should be driven by the needs of the market. Becoming market-driven is critical to intentional product success. But it is not enough to understand your market. You have to sustain your understanding, and take advantage of it, competitively.
How Do You Manage Market Data?
Great product management starts with an insightful understanding of your market. Not just understanding a customer, and not even understanding all of your customers, but understanding your target market. What works for you?
Successful Products: Lucky or Intentional?
Is your product successful because you were lucky, or because you were methodical and intentional?
Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”