How I get up to speed on a new product launch

Every new launch starts the same way. A lot of inputs, not a lot of clarity. Here is the process I use to get from brief to demo-ready.

1. Read the message house

Before I talk to anyone, I read the message house from the core PMM.

What is our positioning? What are the pillars we are committing to? What language are we using and what are we deliberately avoiding?

This is the foundation. Everything I build has to be consistent with it. If I start with product conversations before understanding the messaging, I end up building demos that are technically accurate but narratively off.

2. Connect with the PM

Once I have the positioning context, I go to the PM.

Three questions I always ask: What are we building? Why does this matter? What are the real customer pain points that led to this product?

The last question is the most important. Customer pain points are the backbone of every demo narrative. If I know why a customer was struggling before this product existed, I can build a demo that makes the solution feel inevitable.

3. Connect with the engineering team

The PM gives me the vision. Engineering gives me the reality.

I want to understand what is actually being built, not the roadmap version. What works today? What are the constraints? What does the product do under the hood that is not obvious from the surface?

This conversation usually changes my demo ideas. The technically interesting parts are often different from what the product deck highlights.

4. Get the product in front of me

This starts wherever the product is. Sometimes that is Figma. Then staging. Then production.

At each stage I am asking the same question: how does this actually work? I am not evaluating polish. I am trying to understand the mechanics. Where is the data flowing? What triggers what? What happens when something goes wrong?

Brainstorming use case ideas happens here, not before. I need to see the product moving to know what stories it can actually support.

5. Connect with SEs to validate the use cases

I bring my use case ideas to the SEs before I build anything.

They are the closest to real customer conversations. I ask them: will this resonate? Have you heard customers talk about this pain point? What objections do you anticipate?

This step has killed bad demo ideas and saved me from building the wrong thing more times than I can count. SEs are an underused resource in demo development.

6. Use AI to understand the broader industry context

Once I have a grounded view of the product and validated use cases, I use AI to zoom out.

I want to understand how this concept is being used across the industry. What are the patterns? What are other companies doing? What does the analyst and practitioner community think about this problem space?

This helps me write the "why this matters" part of the demo narrative. The product solves a specific problem. The industry context explains why that problem exists and why it is getting harder to ignore.

7. Keep playing with the product

This does not end.

I keep using the product. I watch what others are building with it. I follow practitioners on GitHub, LinkedIn, and community forums to see how the product behaves in real hands.

The best demo ideas usually come from this stage. Not from the brief, not from the PM call. From watching how people actually use the thing and finding the moment where it clicks.

8. Build the smallest demo that proves the point

One agent. One tool. One call. One visible outcome.

I resist scope creep at this stage. The temptation is to build the full multi-agent network from the start. The right move is to prove the core interaction works first.

Once the minimal version works, I layer in complexity. Each layer has to earn its place in the narrative.

9. Document the gaps while they're fresh

After the demo works, I write down what was confusing, what the docs got wrong, and what I had to figure out by trial and error.

This becomes the most useful thing I can share with other builders.

Gaps in documentation are gaps in the product experience. Capturing them is part of the job.