There is much conversation around how to use the Business Model Canvas (BMC) for new product development and business model iteration.  However, less attention is paid to how it can serve as a tool for requirements definition.

At LeanCog, we use the Business Model Canvas in a variety of ways, one of which is to get a clear understanding of our client’s requirements so we can design enterprise systems that meet the needs of the business and the system’s users.  Traditionally, many requirement conversations would start with “tell me about your business” conversations with a variety of business stakeholders.  Overtime, we ‘ve seen several challenges emerge from this approach:

  1. Different people use a different lexicon to describe the business, and these subtle differences would lead to future gaps or misunderstandings.
  2. Often time whiteboard conversations were unstructured and certain considerations were missed – and these requirements and resulting designs would pass all the way through business acceptance testing and into production before these use-cases were identified.
  3. Without a better tool, conversations would often devolve into using a specific technology’s architecture and terminology to explain requirements, and since most times the client was not an expert in the technology, too many assumptions were loaded into the vocabulary which the client wasn’t aware of.

However, when we use the business model canvas to describe the business, it gives us a common architecture and vocabulary for different stakeholders to share their needs.  When combined with other customer development based practices, of course, we find that this is a very useful tool for defining requirements.

We’ve done this extensively when working with salesforce.com, and here is how we’ve we’ve found it maps to the 9 building blocks of the BMC.

Business_Model_Canvas

Start with the business’s Value Proposition.  I’ve seen systems (poorly) designed where the architects never even asked this question.  They cut straight to “what is your sales/support process”, and never took the 5 minutes to understand the “why”.  Start with a discussion of the business’s core competency and competitive differentiators, and then drive to the products, and eventually to how products are sold.

If the system is to be flexible, and ultimately support the businesses goals, every other aspect of the design needs to rebase against these and be prepared to test and measure these items in the performance of the business.  Specifically though, this leads to designing the opportunity types and product relationship, CPQ flow and an object hierarchy that will support the reports and dashboards which the business is interested in.

Next, define the Customer Segments.   You’ll want to talk to representatives from sales, product, support and BD to get this right, as they’ll all have a different view of how the customers are grouped.   The defined segments may or may not result in different salesforce record types, that will be a detailed design decision, but this will result in a complete view of what type of customers will populate the system.  This is also the place to discuss customer acquisition and the appropriate way to qualify leads and progress the pipeline.

These are the two most important areas as their relationship drives all the other building blocks, so they deserve an adequate amount of discussion.  From here, we can evaluate the remaining 7 building blocks.

Customer Support:  How are customers supported?  Will that be managed via salesforce cases?  Support cloud?  Another system (if so, what feedback needs to make it back into salesforce?).  Will they need self service capabilities such as Customer Portal or Communities?  Make sure this discussion covers all products and all segments defined in the other sections.  Discuss the support requirements here, what are their SLAs, what are their goals of support, and does it contribute to any value propositions (if so, this requires a deeper dive).

Channels:  This is often an overlooked design requirement, in my experience, and why I like the BMC to help tease this out.  People often default to their primary channel when describing the business, and forget about partner sales or referrals because less of that activity is happening within the four walls of the business (by definition).  Having an explicit conversation, not just with sales, but with BD and AR is key to understanding this and making sure secondary channels aren’t just uncomfortable bolt-ons later.

Revenue:  Like channels, this is another often under-discussed aspect of system design.  Many people default to salesforce.com’s default opportunity amount and only later, after the foundation is built, do discussions around how to handle MRR, service contracts, referral agreements, expense accounting, etc…  Highlight all the companies revenue sources (again, go back to AR or someone in the CFOs organization) to make sure all of these are identified.  Rarely does the direct sales team cover all revenue streams, and so when the Head of Sales is the project sponsor, it’s not surprising why these items may be missed, but again, by using the canvas in all stakeholder interviews, you can help minimize these risks.

Costs:  In a salesforce deployment, the costs of the business traditionally have been outside the goals of the system.  However, we’ve seen more and more deployments where some form of cost accounting is starting to work its way into designs, such as tracking time worked on cases, sales compensation accounting, etc…  While many costs of the business will be outside of what is designed into a salesforce.com deployment, use this as an opportunity to get the client to think about where they will want to do this.  Cost accounting is much easier to do from the get go than to implement later on.

Key Activities:  What the business views as its key activities will provide a good starting point for use-cases and may ultimately translate to things like workflow rules, approvals, escalations, dashboards, etc…  For example, if a key activity is lead generation, then integration with an Marketing Automation Tool will be highlighted here.  If it is product development, then being able to collect customer feedback (such as using salesforce ideas) or reporting on adoption rates of new features could be key design requirements.  While some use-cases will be outside the scope of salesforce, and some will be too granular for the BMC, it will provide important insight and future review point into what the business is doing so the system can support these activities for the role that salesforce is meant to.

Key Assets:  This often is all the stuff outside of salesforce that needs to be integrated, migrated, or measured.  If the salesforce.com is designed well, it may eventually become a key asset to the business as well.  If a key asset is user data, this might highlight the importance of integration to a big data tool.  If a key asset is brand, perhaps an agency should come into to design the customer portal, or perhaps a CMS should be put on top of the portal to provide the brand experience.  Since this is what makes the company better than others in the market who are doing the same activities, it is likely to need to be taken into design considerations of all aspects of the business.

Partners:  Identifying all the partners leads to discussing integrations, partner portal requirements, report distribution etc.  Start with just covering all the partners (make sure to talk to BD, since IT or Sales are unlikely to be able to give you a comprehensive answer!).  This is often the key for area for dependency and integration conversations, as well as project teaming (since some partners may be those building other systems).

We’ve seen several benefits from taking this approach:

  1. Our conversations across different stakeholders become more consistent and efficient
  2. Change control conversations become less contentious
  3. The number of surprises at launch go way, way down.
  4. Furthermore, if you take an iterative, feedback based approach, these are a good place to capture your assumptions and priorities that you can test throughout your deployments and develop a release roadmap.

Let us know if this is helpful, and we’d love to hear your feedback if you try this approach.

Reposted from Paul Mackinaw’s blog

Leave a Reply

Your email address will not be published. Required fields are marked *