top of page

Part 2: Significance of Solution Envisioning

"People don't want to buy a quarter-inch drill. They want a quarter-inch hole!"


An upfront process discovery is the foundation for Solution Envisioning. Refer to the previous article on process discovery best practices.


The buyer needs to see how a potential solution fits into his eco-system connecting people, processes and existing systems. It bridges the gap between Business and IT through the integration of concepts and techniques from both best-of-breed business strategy and software development methods.


The process of solution envisioning will clearly call out the risks and the benefits of the proposed end state and what pain points it directly addresses. This is a critical milestone for the seller as it earns technical validation from the buyer if done correctly.


Here's my 3 step prescription on what a good solution envisioning process could look like:


1. Current State


Solution envisioning, also referred to as Future State in the buyers journey, is best depicted when started with the Current State representation of the current state.


Both Current and Future State are best represented in a process map diagram connecting people, processes and systems together. Here's an example:


A depiction of the Current State process captured from process discovery must clearly call out the flow of business transactions, triggers and hand-offs of the transactions along with user touch points. The intent should be to highlight process inefficiencies, and potential gaps with user/customer touch points in the Current State process.


2. Future State


The Current State lays a good foundation in terms of what pain points are addressed and also to ensure that the buyer and seller are on the same page. The Future State is better depicted in the same format of connecting people, processes and systems. I personally prefer a journey map (see below) where key milestones in the process are called out and depicts the channels of interaction and a clear separation of stakeholders tied to different process milestones, channels, and systems.


A user journey map like this is more of a Level-1 which can presented and articulated to business and IT stakeholders alike to get initial buy-in. This can be preceded with subsequent representations of processes and systems with specific architecture diagrams or Level-2 process maps. For a seller, this is the critical juncture in the deal cycle to influence the solution with their offerings. Personally, I prefer a generic process map as Level-1 and a vendor specific architecture as a Level-2. See an example for a Level-2 map below.


A Level-2 map or a systems view is most appropriate for an IT stakeholder. The key here for the seller is to envision the solution keeping the bigger picture in mind. It's often tempting to get carried away with vendor specific architecture which the buyer might view as a biased solution. A good practice here is to stay neutral overall, but pepper in the strengths of your solution and map it to the critical aspects of business process.

3. Aid the buyer get to MVP state with a roadmap


Buyers often don't give a nod until they know for sure that the seller's solution can be successfully rolled out and adopted within their enterprise. Sellers cannot assume a technical win post consensus from the buyer on the Future State. To allay any fears on the buyer's mind on roll out and adoption, a good practice is to depict a roadmap in terms of how the buyer can get to a MVP (minimum viable product) state and beyond to an ideal state.

Personally, I would recommend a phased approach with key objectives to be accomplished in each phase and what business outcomes will be expected out of it. As a seller this presents an opportunity to highlight how easy and quick their solution can provide business value. The buyer not only gets a clear view of the roll-out and business outcomes, they also get to see the big picture of the path to the Future State. This activity is a must for a sellers participating in huge transformation projects.



While Solution Envisioning by itself may not guarantee a technical win, it is a critical step toward earning credibility. It's a confidence building measure where buyers get to realize that the seller understands their world, specifically processes, systems and sub-systems and more importantly the pain points and business drivers. Now, it's time for the Proof-of-Concept, let's discuss how to keep it on the rails.



Prasanna is a solutions selling leader and architect with 17 years of experience. He helps enterprises in process automation, content collaboration, customer experience platforms and application integration. He is currently a Staff Solutions Engineer at Box.


Connect with Prasanna on LinkedIn.

bottom of page