Archive of Requirements Models Articles
August 30th, 2010

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.

Posted in Business Analysis, Ishikawa Diagram, Kano Analysis, Product Management, Requirements, Requirements Models | 12 Comments »
August 24th, 2010

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.

Posted in Agile, Foundation series, Requirements, Requirements Models, Software development, Testing, User Stories | 20 Comments »
April 14th, 2010

“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.
Read the rest of the article…

Posted in Agile, Kano Analysis, Product Management, Requirements Models, Software development | 33 Comments »
March 31st, 2010

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.
Read the rest of the article…

Posted in Kano Analysis, Marketing, Product Management, Requirements, Requirements Models | 15 Comments »
March 1st, 2010

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.
Read the rest of the article…

Posted in Interaction design, Product Management, ROI, Requirements, Software development, UX, User Stories | 19 Comments »
February 23rd, 2010

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.
Read the rest of the article…

Posted in Business Analysis, Kano Analysis, Product Management, Requirements, Requirements Models | 12 Comments »
January 5th, 2010

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.

Posted in Administrivia, Agile, Business Analysis, Prioritization, Product Management, Project Management, ROI, Requirements, Requirements Models, Requirements gathering, Software development, Use Cases | 5 Comments »
November 30th, 2009

Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.

Posted in Business Analysis, Ishikawa Diagram, Product Management, ROI, Requirements, Requirements Models | 14 Comments »
November 3rd, 2009

Design-Free requirements are important for two reasons, and hard for two other reasons.
Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.” Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Posted in Agile, Business Analysis, Interaction design, Interface Design, Product Management, Requirements, Requirements Models, Software development, UX, Use Cases, User Stories | 22 Comments »
September 28th, 2009

Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems. I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.

Posted in Kano Analysis, Product Management, Requirements, Requirements Models | 7 Comments »