Product Concepts are the blueprints from which our software requirements are built. They can determine large amounts of effort needed for requirements gathering, building, and shaping, and keep projects aligned under a single banner. There are various approaches to understanding the Product Concept from a requirements perspective, but there are essentially two fundamental approaches from which to build a Product Concept. First you have what I would call an “inductive” approach. You go and collect requirements and, piece by piece, you build a product concept from which to derive more requirements. A second approach is what I would call “deductive”, you start with a product concept and ask various stakeholders what they desire, detracting from the product concept until you have a solid view of the product that is wanted. There are pit-falls to both approaches, but they can be mitigated through the Business Objectives Model.

So far so good, but let’s try and put some visuals to this.

Let us pretend that the above image is a representation of your requirements gathering. Each dot represents a requirement and its location would be its taxonomy, maybe connecting a few here and there as you undergo requirements discovery. However, there is no shape. The pitfall is obvious with this approach – Even if you were to derive a shape (product concept) through arbitrary association, can you 100% assert that this is what it is supposed to be?

Here, the product concept has been derived, nearly arbitrarily, through the connections of the requirements that were gathered. This is clearly an elephant. However, the approach to get to the elephant leaves a lot of gaps that could be missing. Is that how long the trunk should be? Are there 3 legs, or 4? These are the questions that a business analyst would continue to ask to get closer and closer to an entire view. However, as we’ve already demonstrated, there is no possible way a 100% view can be derived since the approach adds from the bottom-up. In fact, 100% is in no way defined. Perhaps at this point one may decide to choose the elephant as the product concept, and begin the deductive approach.

This is an elephant, and it is our product concept. As you can see the elephant is complete, we have started with the idea (the form of the elephant) which is vague, wholly-encompassing, and gigantic. Here we can take our elephant to our stakeholders and ask, “What do we need to remove from the elephant to make it the elephant we want?” This approach also helps with scope control and prioritization. If a stakeholder says, “That elephant needs a horn on its nose,” you can politely inform them that elephants don’t have horns on their noses, but that rhinoceroses do.

The Business Objectives Model is a separate exercise to discovering your product concept, but it does not necessarily begin with requirements or a product concept. It begins with problems. The discussions of “What is wrong with your business?” leads to answers that assist in defining the product concept more thoroughly, completely align with the true troubles of the business, and eventually lead to true solutions to those problems. Imagine your stakeholders tell you that they need claws, large teeth, orange and black striped fur, and that they needed it to be an elephant. This, unfortunately, is the state of most businesses, and a large reason why projects fail from scope creep and budget issues.

This is not an elephant. This is a tiger. Does your business need a tiger but demand an elephant? Construct a Business Objectives Model, going through the complete exercise of defining your business problems, your business objectives, tying everything to money, and ideate the product concept from those, then show it to your business stakeholders. With any luck you might be able to save your company a lot of money. Oh, and you get a tiger too.