Product Scoping Decisions

If you have been around Product Development or Systems Engineering long enough, you could write some horror stories describing how feature bloat killed a great product. Regardless of your product development methodology (waterfall, lean startup, agile, etc.), every product has a pattern of product scoping decisions that are the essential, common tool that provides focus to your solution.


While depicting these decisions as a funnel or series of screens isn’t a perfect metaphor for a set of interacting decisions that may be made in parallel, you get the point.  The product development process should start early to say NO! or NOT NOW! to many ideas about what the product could be/do and say YES! and WHEN! to a very focused-subset of these alternatives.  These decisions should be data-driven to the extent that is possible to gain customer and end user validation of key concepts and assumptions.

Of course, you have already made a set of business scoping decisions (Vision, Value Chain Strategy, Target Markets, Positioning, Product/Services Portfolio) to get to this point on Product X.  Now you are ready to define the scope of this product from the viewpoint of the customer.  That starts with an understanding of the customers’ unmet needs, perhaps expressed as jobs-to-be-done and associated pains-to-be-relieved and gains-to-be-created.  Your task is to transform these unmet needs into a lean-mean set of features delivered in a product that these customers want to use and are willing to pay for.

Your first decision, Use Cases to Support, will whittle down the list of potential jobs-to-be-done to a manageable high-priority set that will give your customer new ways of living and working.  For each use case that you choose to address, you may evaluate your Value Proposition against the status-quo and potential competitors.  This will ensure that your solution provides enough differentiation to catch and hold the attention of potential customers and overcome the inertia that makes the status-quo, do-nothing alternative their default course of action.

Once you have determined the unique value that you intend to deliver, you will translate that value equation into Use Case Flow or User Experience (UX) alternatives.  There may be many ways to deliver on your value promise, so this decision forces you to get specific on how you will change the user experience for the better, e.g. simplify their life or work. Because use cases can be modeled as a series of actions, this decision evaluates the efficiency and effectiveness of various flow alternatives.

Any product can be thought of as a way to provide new leverage or a level of automation to the end user.  This implies a Product Role decision that defines which actions in the use case will be enabled/supported by or accomplished fully in the product, rather than by the continuation of current manual user actions.  The result of this decision contributes (one use case at a time) to the overall Concept of Operations (CONOPS) for the product.

The final product scoping decision, Feature Set, translates all the use case actions that have been allocated to the product into groups of packaged features (configurable functionality for sale) and prioritizes the build-out of these features.  This decision creates the Product Roadmap which says YES! NOW! or YES, BUT LATER!

Of course, each of these decisions have a criteria pattern that represents the important factors to consider when evaluating various alternatives.  These criteria do the screening to kill off bad ideas that would bloat the product, drive up development costs and contribute little to sales or customer satisfaction/loyalty.

If you haven’t thought of the product scoping process as a set of explicit, pattern-based decisions, I encourage you to contact the Decision Driven® Solutions team at  We would love to run one of your product concepts through this decision gauntlet in record time so that you can get on with the fun of building out a great solution.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts, Decision Driven Product Development, Decision Patterns and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s