Twilio
Twilio Pair: Helping developers experience Twilio before committing to the build
Product strategy · Developer experience · Prototyping. Status: Prototype · Internal evaluation
I conceived, designed, and engineered an interactive prototype to help prospective customers experience Twilio before creating an account or writing code.
Status
Unpublished prototype · Internal evaluation
The opportunity
The opportunity was a missing step between discovering a product and implementing it: helping developers validate what they wanted to build. Start / Pair explored how a guided, interactive experience could make that decision easier and provide a clearer path into implementation.
At the time, the standard “try Twilio” journey asked customers to sign up and enter the console before they could experience what the product would do for them. Existing demos were often built for sales conversations or in-person experiences.
That left an important question unanswered: “How do I know if I want to build this yet?”
My hypothesis was that building should not be the primary process for idea validation. Developers needed a way to see an outcome, understand its relevance, and gain confidence before investing in setup and implementation.
The audience included developers evaluating Twilio and builders who understood their desired outcome but were still determining how to achieve it.
What I owned
I took the concept from identifying the problem to designing and engineering the prototype. I also gathered internal feedback, worked through its relationship to existing developer experiences, and coordinated with stakeholders on the requirements for a potential release.
The prototype’s guided journey let a developer select a use case, answer approximately five questions about their requirements, experience an interactive live demo without supplying credentials or completing setup, and continue to a shareable technical brief with code, implementation steps, and an account-creation CTA.
The experience was designed around an approximately 60-second first demonstration. This was an experience target, rather than a measured improvement in customer activation.
The decisions behind the experience
Define the problem before expanding the product
Early feedback raised a larger opportunity: an AI copilot that could generate bespoke guidance or a finished implementation.
I considered that direction, but questioned whether it solved the immediate problem. Someone still deciding what to build needs a different experience from someone ready to implement it.
I advocated for idea validation as the initial purpose. A guided experience could offer clearer boundaries and more predictable outcomes while leaving room to explore conversational assistance later.
Connect the demonstration to implementation
A successful demo needed a useful next step. Internal feedback pushed the concept beyond showing an outcome toward helping developers carry that outcome into their own work.
By April, the documented flow included a technical handoff with code and implementation guidance. We also explored connecting demo outcomes to matching Code Exchange templates for quick deployment or download.
That connection would give the experience a role within the broader developer journey: discovery, validation, implementation, and account activation.
Make the experiment measurable
I identified the funnel we would need to measure: use-case selection, demo completion, handoff views, and signup clicks.
The prototype included a UTM-tagged signup CTA, and I requested analytics support to connect the stages. The goal was to evaluate whether the experience helped developers move forward and identify where they stopped.
What the work achieved
| Measure | Reported result |
|---|---|
| Product development | Designed and engineered an interactive prototype for experiencing Twilio before account creation. |
| Iteration | Gathered internal feedback on the experience, implementation handoff, and product boundaries. |
| Measurement preparation | Added a tagged signup CTA and specified the funnel events needed for evaluation. |
| Release preparation | Advanced QA work and coordination with Web and Legal for a potential release. |
The project remained an unpublished prototype. It did not produce validated public adoption, conversion, or revenue results.
What I learned
The central product decision was determining what developers needed at this particular moment in their journey.
Product recommendations, interactive demonstrations, and implementation tools serve related but distinct needs. Defining Start / Pair around idea validation helped clarify its purpose, its scope, and how it could connect to the rest of Twilio’s developer experience.
Internal feedback also sharpened the importance of the handoff: showing what is possible is only part of the experience. Developers need a clear next step they can understand and act on.