Category Archives: Requirements gathering

Articles, tips, and techniques of eliciting requirements. Business analysts and product managers both practice software requirements gathering. These articles provide tips on how to gather requirements and create conversations about requirements gathering.

Market Problem Framing Example

picture frames photo from Jessica Ruscello

As Steven Haines first told me, “strategy first, roadmap second.” There is a step between the two – deciding which problems you will focus on solving with your product. Strategy defines the context for product strategy, and your product roadmap is a planning (and communication) tool for executing your product strategy. Understanding how problems are framed in your market is critical to developing a successful product strategy.

Continue reading Market Problem Framing Example

Minimum Valuable Problem

redacted use case dependency thumbnail

Defining and building a good minimum viable product is much harder than it sounds.  Finding that “one thing” you can do, which people want, is really about a lot more than picking one thing.  It is a combination of solving the minimum valuable problem and all of the other things that go with it.  Solving for both the outside-in needs and the inside-out goals is critical.

Continue reading Minimum Valuable Problem

Professional Services and Improving Your Product

Prioritization at whiteboard

How do you work with professional services, consulting, field engineers, etc. to make your product better? Do you just treat their inputs as yet another channel for feature requests, or do you engage them as an incredibly potent market-sensing capability?

Continue reading Professional Services and Improving Your Product

Why Not What – An Example

Obscenely complicated WW2 U-Boat controls

Forbes quoted Steve Jobs as saying “I’m as proud of what we don’t do as I am of what we do.”  This is a really enlightened perspective – and a way to enforce focus from the top down.  Before you can drive a “this goal is more important than that goal” focus, you have to make sure you’re actually focusing on the goals.

Continue reading Why Not What – An Example

20/20 Vision – Innovation Game in Action

Having an outside-in bias as a product manager is important – you need to understand how your customers (or your customer’s customers) would value capabilities you might build into your product.  When running a workshop to collect that information, playing some “serious games” is a great way to get more and better information.  We ran a few 20/20 Vision games last week, to great effect.

Continue reading 20/20 Vision – Innovation Game in Action

Why Do Products Fail? – Picking the Wrong User Goals

Continuing the series on root causes of product failure, this article looks at the impact of focusing on the wrong user goals.  Even if you have picked the right users, you may have picked the wrong goals – creating a product your customers don’t really need, or solving problems that your customers don’t care about solving.
Continue reading Why Do Products Fail? – Picking the Wrong User Goals

Important Problems – Comparing Products Part 4

If you understand the important market problems, you can make a good product.  If you understand how important each problem is, for each group of customers, you can make a great product.  If you’re new to this series, go back and start at the first article, we’ll wait for you right here.

Continue reading Important Problems – Comparing Products Part 4

Market Problems – Comparing Products Part 3

Comparing products without an understanding of the important market problems by which to compare the products is a waste of time.  This is the third in a series on comparing products – jump back to the introduction if you haven’t already read the previous articles.  Go ahead, we’ll wait, then come back.

Continue reading Market Problems – Comparing Products Part 3

Everything Old is New Again

A lot of teams that I’ve worked on and with get hung up when thinking about defining requirements for “migration projects” and “system upgrades.”  There’s some intangible barrier to being market focused when it comes to improving existing internal systems.  Every new product represents a solution to an existing problem.  Why do so many projects move forward with teams that are blind to the actual requirements?

Continue reading Everything Old is New Again