[Audio] The SE Best Practice Series Module Two: P-O-C.
[Audio] Objectives of a Proof of Concept 1 Demonstrate value 2 Be consultative 3 Progress the deal Demonstrate Value Do your homework (research and discovery) Tailor demo to customer’s needs Demonstrate technical and business value Simplify complex concepts Keep it concise and focused, self edit Be Consultative Engage the audience Build trust and credibility highlight you/product/customer experience Have an opinion / point of view Professorial vs conversational Tell a story Progress the deal Showcase differentiators Align to customer Catalyze a decision.
[Audio] Introduction – Goal of the P-O-C Goal A POC should serve as the last step of the technical evaluation. Plan for the P-O-C Do your homework & be prepared Agreed upon use cases It should be run with an agreement from the customer that a successful P-O-C demonstrates we have met all their requirements Should be documented in P-O-C document Deal Breakers Avoid conducting a P-O-C for a project without a budget, a defined selection date, or a license deal, unless approved by your Sales S-V-P--. Identifying Critical Factors & Risks Understand requirements Evaluate the players.
[Audio] Planning for the P-O-C (Preparation) Prep up front Perform the installation before going onsite to start the P-O-C--. Limit the scope to one P-O-C type. Customers requesting benchmarking, functionality use cases, and a DevOps use case simultaneously are asking for too much; determine which aspects can be delivered through alternative means like benchmarking documents or customer reference calls. Always aim to go last. The first vendor often encounters issues that are resolved, smoothing the path for the next vendor. Timelines This lead time is for performing a remote install and testing connectivity of all systems, plus gives time to try to build anything custom ahead of time. Try to scope the P-O-C effort itself to a one week effort..
[Audio] Planning For a P-O-C (POC Document) Complete the P-O-C document Use only the parts of the document that make sense for your P-O-C--. Get the customer to agree to the use cases and success Criteria. This is a living document to be updated during the P-O-C--. As noted earlier, ensure the P-O-C serves as a closing step, the final stage of technical evaluation with customer agreement that success means requirements are met. POC document priorities Obtain written confirmation of the prioritization of use cases to ensure the most critical ones are addressed first. Ask the customer, "Which use cases pose the highest risk to your business and prevent you from sleeping at night?". Regarding extra credit use cases (those outside the core set or not done by other vendors), make sure to designate this as extra credit. Confirm this is a productive use of your time and identify if they align with requirements from an influencer or decision maker who couldn't get them into the core set. Only undertake these if there is sufficient time and they contribute value towards securing a win..
[Audio] Deal Breakers Commitment from Customer P-O-C should not be run concurrently, with other vendors (if in customer environment). Individuals evaluating the P-O-C should be the same if multiple vendors are included. If the P-O-C is being shadowed by someone on the customer side, we should have their time dedicated to the P-O-C for the entirety of our time onsite or on Zoom P-O-C use cases should be the same for all vendors. We need fast and dedicated access to system owners when we are integrating with target systems and applications..
[Audio] Identifying Critical Factors & Risks Understand objectives and decision points It is essential to determine the actual decision points for the selection. These are not always the use cases initially shared by the customer. Sometimes, underlying objectives like deployment time or critical items such as the ability to migrate from a legacy I-A-M solution are key decision criteria, even if they aren't explicitly identified until later. You must figure these out before commencing the P-O-C-. Understand the players Evaluate relationships by identifying connections, influencers, and champions. Assess if the competition holds a stronger position in these areas. M-A-E's should lead this effort, but you must inquire to ensure they are aware; if not, escalate to your SA Manager. Consider partner influence by determining which SIs have influence at higher levels and which can assist based on requirements. M-A-E's and the Partner team should manage this, but you need to ask. Evaluate executive influence: Confirm executive alignment, particularly for larger deals, and check for connections through executives or the Board. M-A-E's should drive this, but inquiry is needed. Preparation time for the P-O-C is critically important. Identify areas where the product seems complex and where custom building is necessary so this can be done in advance. Deliver any custom work in a manner that does not frame the product's flexibility negatively..
[Audio] Communication during P-O-C Communication is Vital SE’s need to communicate, who does what M-A-E should be involved and present Open and Close P-O-C Agree on Use cases in P-O-C document Hold Opening and closing meeting Understand your audience Post P-O-C Activities Create Folder, and store documents Clean up P-O-C environment.
[Audio] Communication is Vital SE’s need to Communicate If multiple SAs are on a P-O-C--, one SA should handle the "show and tell," educating the customer, delivering completed use cases, and providing "air cover" for the second SA. The second SA is tasked with setting up use cases requiring work beyond standard configuration and also troubleshooting Be mindful that the second SA's work might be perceived as coding, potentially supporting competitor F-U-D about complexity. Clearly communicate the work being done. Make it explicit both verbally and in writing that you are setting up use cases, not coding, and be prepared to show all completed work M-A-E role If the M-A-E is present onsite (which is recommended for part of the POC), they should ask direct questions about progress and concerns and also socialize how things are progressing with customer personnel not directly involved in the P-O-C Daily updates are crucial. Send an update to the wider Ping team so everyone is aware of progress and can offer additional help if needed. Hold a daily checkpoint meeting with the customer to voice concerns or roadblocks and assign ownership for open items, especially those requiring customer resolution Show prospect status Maintain a socialized checklist. Use the P-O-C document to show progress, and confirm success of each step.
[Audio] Opening and closing the P-O-C effectively is important Opening Make sure to get written confirmation that the use cases have been completed (Use the P-O-C Document) Hold an official kick off meeting including all stakeholders. Summarize the planning steps finished and the plan for executing the P-O-C--. Highlight the business benefits the project will deliver Closing Hold an official closing meeting. Plan for possibly two separate meetings: one technical and one business focused In the technical meeting, emphasize product capabilities, fit for requirements, and ease of use. Demonstrate how key use cases were set up For the business audience and decision makers, use limited or no demos. Instead, focus on the value the use cases will provide to the customer. Differentiate how Ping is the right and best choice based on our understanding of the customer's definition of value.
[Audio] Finally, post P-O-C activities include Post Creating a Google Docs folder containing all P-O-C artifacts. Include links to assets stored elsewhere. The objective is to make the work performed reusable. Document use cases in P-O-C Document, that was created on first call. Backup your P-O-C Journeys and configs (A-I-C--) in case you need to restore your environment. Document the custom nodes used for the P-O-C and create an archive of these nodes. Save any Davinci Flows and share on Confluence.