A market can be thought of as the collection of contexts in which you might sell your product. You can split your market into a set of market segments. Each of those segments represents a group of customers, each of whom shares a set of problems for which they would pay for solutions.
Category Archives: Requirements Models
Atomic Requirements
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements are important.
Sprint Backlog – Don’t Solve Half of the Problem
Every team that transitions to agile faces this problem – some stories are too big to fit in a single sprint. Most of the teams that I have worked with have the wrong instinct – to solve half of the problem for all users.
The right approach is to first solve all of the problem for a subset of the users.
Verifiable Requirements
Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can’t verify that what the team delivered is acceptable, neither can the team. This may be the most obvious of the rules of writing requirements – but it is ignored every day.
Read the rest of the article …
Foundation Series: Inside A Scrum Sprint
People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me. People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.
Read the rest of the article …
The One Idea of Your Product
“For what one idea do you want your product to stand in the mind of your customer?” I heard Roger Cauvin ask that question at the most recent ProductCamp Austin [correction - he said it here - thanks Roger], and the quote has been jumping to the front of my mind almost daily ever since. Maybe by writing about it I can exorcise the demon and get back to using the idea instead of being haunted by it.
Minimum Market Acceptance
April Dunford just presented Startup Marketing 101 at DemoCamp Toronto. Great ideas from the ‘marketing and your startup’ point of view. I’ve often said that product managers and product marketers care about much of the same market data, they just do different things with it. The idea of minimal feature set came up in April’s presentation – this article talks about product management, agile, and initial market acceptance.
Measuring Great Design – Mad Libs Input Form
I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.
Bonus: the idea is cool.
Complete Requirements
You give your requirements to the engineering team, and they look complete. The team builds your product, you launch it and the market soundly rejects it. Why? Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.
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.
Latest Articles
Comments on all Articles
