Bringing the lightbulb to market

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

It’s 2 AM. You’ve been banging your head at the most challenging problem of your career. You promised the largest city in the country that you’d invent what will change how its’ population (and humanity) operates. Your reputation is on the line, and you can’t sleep.

To your left are stacks of scrapped diagrams and your right, disjointed prototypes. The past four months, you’ve focused on producing an energy efficient method of light, that is capable of maintaining brightness, is safe, and can be distributed long distances. A Herculean task, that nobody in the world has done. The press is calling you a phony, but you don’t care you, truck on.

These four stressful months of no sleep, neglecting your relationships, and destroying your body have finally paid off. The newspapers are ecstatic with the output of your hard work — you’re a sensation. Now it’s time to bring your invention to market, but first: time to rest.

Thomas Edison was known to work in bursts. He would work his hardest for months at a time, prioritizing his goal over, unfortunately, family and health. These “sprints”, were understood by him to be unsustainable, which is why he chose to vacation after each one: a recovery.

Headquartered in Menlo Park, New Jersey, he’d frequently roadtrip out west with his family following most sprints, and venture around Europe for others. Is this a mindset that’s been lost over the generations? Are we neglecting the “recovery” after our sprints?

In January of 2022 I embarked on my own, microscopic lightbulb moment, only my charter was building a system to take a new product to market. Not nearly as significant for humanity, but it was a hyper complex product for a global, public company. The end-users are savvy engineers, and the product itself is in the NLP (Natural Language Processing) space — a branch of artificial intelligence. The challenge statements I identified to bring this nascent, complex product to market were three fold:

1. Engagement — What’s the best way to engage with our most strategic customers on this product?

2. Enablement — How do we teach employees to sell, implement and support the product?

3. Improvement — How do we ensure the product is incrementally improving with each interaction?

Building systems to address these three problem statements was my mission, it’s time to sprint.

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.

Each conversation with qualified leads (prospects), lent to enriching our understanding of what the market was looking for — required capabilities. These are requirements that our product has in order to achieve a customers’ desired business outcomes. Cataloguing these in the customers’ own words was critical for our ability to scale the engagements.

For companies offering “full text search” as a feature in their product(s), one required capability (RC) could be: we need to build a user experience that is tolerant of user errors, also called fuzzy search.

These engagements would continue until we had a system of cataloguing, and enriching:

• 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?

At this step, we needed to democratize the ability to enrich this list, inclusive of the four bullet points above. Every employee should feel emboldened to add to the list as they uncover new customer needs.

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.

Two things are needed to enable the salesforce:

• 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

To demonstrate this, we’ll fall back on the same example above: fuzzy search. We already have the RC, discovery question(s) and reference. It’s time to build the proof.

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:

Now, any pre-sales engineer can use this Jupyter notebook to “prove out” the fuzzy search capability. Since the proofs are all standardized on the same dataset, it’s trivial to pick up and go for any new employee and any new RC. The list expands.

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”

At this point we have a system for cataloguing RCs, as well as enabling the global salesforce. Now, we need systems that catalogue perceived knowledge (and product) gaps aligned to each RC.

Let’s use the tried and true, fuzzy search example:

• 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.

Since we’re both engaging with customers that use the feature and learning how to go deep on it ourself, we’re ripe to identify gaps in each of the above bullet points.

The product improvement step is the most challenging, but also the most important because it’s the only piece that scales infinitely. The key is to reduce the friction and time-lapse between input (customer engagements) and output (public facing assets) — the product improvement feedback loop.

I write this after my own lightbulb experience. Though I don’t consider the goal complete, the product: Atlas Search, has reached its’ own inflection poin: the team of GTM Search Specialists has grown beyond just myself. The sprint “cycle” was complete, it’s time to recharge.

I write this from my self-converted camper van, in Nova Scotia Canada. My method of recovery is a combination of adventure (mountain biking, hiking and paddle boarding) and solitude (nobody around for miles). It’s an obscure recharge method, especially for someone that lives in the very city that Thomas Edison originally promised the lightbulb to (New York), but it’s worked for me.

Your inflection point:

• What’s your sprint? Your lightbulb moment?

• How do you plan on recharging? How long do you need?

I’ll soon be driving down the New England coast to avoid the heat and return back to NYC to perform my very next sprint. Thanks for reading.

Addendum

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

Obligatory: