Develop and validate a demo
As you start to envision the solution that you will propose, you might consider sharing a demo to validate requirements with your stakeholders and to help build confidence in the platform. When a customer is confident in the platform, they are more willing to accept your proposed solutions with enthusiasm.
Demos can take different shapes and forms, depending on the solution that is being proposed. The following approaches are some of the most common:
Out-of-the-box - This type of demonstration highlights one or more of the apps that don't have customizations. This demo is often performed by presales resources and doesn't involve the solution architect. This method is an effective way to get customers up to date with the core product features. The negative aspect of this approach is that it doesn't help the customer envision their solution on the app. You can mitigate this issue by including relevant sample data to their business.
Prebuilt demo - Many partners specialize in particular verticals or solution areas and invest in developing prebuilt demos that contain their own intellectual property that tailors the out-of-the-box base solution with their designed value-add. This approach helps the customer see their particular problem area because it often uses the vertical language in the app. Additionally, this type of demo hides topics that aren't appropriate for the solution area that might distract the customer. While the solution architect isn't typically involved in demonstrating this prebuilt solution, they were likely involved in helping compose it at some point. In fact, the solution architect should potentially consider proposing demonstrating the prebuilt solution when they find themselves building the same prototypes repeatedly.
Prototype - This approach takes the out-of-the-box state and, with the customer's needs in mind, performs minimal tailoring of the app to reflect the customer's needs. The main benefit of this method is to help the solution architect
tell a story during the demo that the customer can relate to when trying to solve their particular objectives. The solution architect is often involved in helping customers identify their objectives by using the envisioned solution to help either build or guide the team to produce the prototype.Proof of concept - Proofs of concept should be built to prove that a concept works and typically involves a specific component or activity in the proposed solution. Frequently, this method is done during the design phase but can also be used during presales when the customer needs to see the concept work in the context of their proposed solution. The solution architect typically drives the need for this method and is involved in driving the effort. Unlike a prototype that usually has a straightforward path to completion, proofs of concept might try multiple approaches to reach the desired goal.
It's common to interchangeably use the prototype and proof of concept approaches and, from a customer's perspective, the difference typically doesn't matter. Your goal should be focused on telling a story and bringing your proposed solution to life, which will help the customer see their problem solved by the proposed solution. You should also consider reducing risk by eliminating unknown issues that might contribute to the customer's current problem.
Solution architect involvement
The solution architect, along with the sales team, should be involved in identifying what should be demoed and what approach to use (for example, out-of-the-box versus prototype).
How involved a solution architect should be in building a prototype or proof of concept varies greatly across projects. These efforts commonly involve multiple skillsets and a decision point of who should be involved in building. Often, the solution architect will find that if they simply do all the work themselves, it might take a few hours, whereas coordinating across a team of diverse resources and having to explain the need might take a few weeks. Solution architects should make sure that they involve others in situations where it's not advantageous to complete the work by themselves.
Keep or discard
When you build a prototype or proof of concept, you should realize that quick wins might not translate to a best practice for production-ready solutions. Best practices aren't difficult to follow; however, if you want to quickly showcase an idea, it's easier to develop an impromptu idea than use an established best practice to plan for a larger solution. You should decide on this approach in advance because, if you want to carry the assets forward, you will need to ensure that these assets meet your standards and aren't shortcuts that can't be remedied easily.
Manage expectations
Creating a demo to showcase your proposed solution can be almost effortless; therefore, it is important to manage your expectations. Commonly, after a demo has been given, a customer immediately accepts the proposal and asks when they can go live with the solution. The best way to manage this scenario is to be direct by saying that while what you are showing might look complete, it doesn't have all the security, automation, and other enhancements that are necessary for going live. It's important to have this discussion right away rather than assuming that the customer understands that your demo is simply a demonstration and not the final solution.
Exercise: Demos for Woodgrove Bank
Use the following questions to help you plan a potential demo for Woodgrove Bank:
- What type of demos would you create for Woodgrove Bank?
- Are you able to craft ideas for a good proof of concept that could showcase some extraordinary functionality?