Bringing the lightbulb to market - sprints and recovery in life and business.

Engagement

Every product starts with talking to users, so I loaded up my calendar with customer meetings with the hope of learning. Sales was secondary. Understanding how to build a growth engine that scales was primary.

  • The RC itself — what are customers needing?
  • The discovery question — how do we learn that the customer needs this?
  • The reference — what do we need to learn in order to fully articulate it?
  • The proof — how do we demonstrate the capability?

Enablement

As the system to enrich required capabilities was built out, in parallel, we needed to enable the global pre-sales force on selling this product using our learnings. We start with the required capabilities.

  • Education — Teaching how to extract the pains and demonstrate business value for our customers
  • Validation — Showcasing that the pre-sales engineer is confident extracting these pains and articulating how we solve them

What is a proof?

It’s a “guide” that walks a pre-sales engineer through how to demonstrate this required capability. I prefer to use Jupyter notebooks to achieve this, as they don’t require any heavy lifting to get started. Just download the notebook, and click Run:

https://github.com/esteininger/atlas-search-guide/tree/master/foundations/2-basic#fuzzy

Improvement

All of this engagement and enablement of the salesforce is great, but nothing compares to actually improving the product — the goal, after all is to create a self-service growth engine. When we say product, we’re referring to every public-facing touchpoint, inclusive of:

  • Documentation — The lifeblood of how a developer interacts with a product
  • Tutorials — Step-by-step guides to build features, inclusive of application context
  • Error Messages — Guiding a user towards a path to resolution when stuck
  • SEO — Meeting developers where they are, and pointing them to the right material, “just-in-time”
  • Documentation — Including use cases for how and when to modify the maxEdits option in the fuzzy parameter.
  • Tutorials — Creating a guide that walks users through the end-to-end creation of a typo-tolerant user experience.
  • Error Messages — If a user tries to include a value beyond the maxEdits upper bound, point them to the documentation to indicate why this isn’t possible.
  • SEO — Answering questions within various Google-first forums like StackOverflow to align with how engineers build.
Cell booster, solar panel and roof top fan can be seen from this Oregon Badlands shot last year. My trail pup posing magnificently in the foreground.
From left to right: off-grid electricals, mountain bike, tubs for hiking/backpacking, stand-up paddle board, 32 gallon water tank, socket for outdoor shower/bike wash/dog wash.

Your inflection point:

  • What’s your sprint? Your lightbulb moment?
  • How do you plan on recharging? How long do you need?

Addendum

This approach to sales is a fork of the MEDDPICC sales methodology, as indicated here:

https://meddicc.medium.com/lessons-learned-from-implementing-meddpiccr-a-year-on-25cafef1330b

Obligatory:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store