DEV Community: Peter Strauss

Your GTM Motion Is a Product. Design It Like One.

Peter Strauss — Mon, 27 Apr 2026 11:57:06 +0000

Most companies still treat go-to-market like a campaign.

They plan a launch.

They write messaging.

They brief sales.

They publish content.

They run outbound.

They measure pipeline.

Then they move on to the next push.

That model worked better when buyers had fewer options, fewer channels, and more tolerance for a sales-led process.

But the buying journey has changed.

Today, B2B buyers move across many channels before they ever speak to sales. They read reviews, test products, ask peers, compare vendors, watch demos, scan docs, consume content, and involve more internal stakeholders than before. According to McKinsey’s B2B Pulse research, B2B customers now use an average of ten interaction channels in their buying journey, up from five in 2016. More than half want a seamless omnichannel experience, and buyers are likely to switch suppliers if that experience feels broken.

This is why GTM leaders need a new operating idea:

Your GTM motion is not a one-time project. It is a product.

And like any good product, it should be designed, tested, measured, improved, and shipped continuously.

The current view: GTM is becoming part of the customer experience

GTM used to be viewed mainly as distribution.

The product team built the product.

Marketing created awareness.

Sales converted demand.

Customer success handled retention.

That separation is getting weaker.

In modern B2B, the GTM motion itself is part of the product experience. The first ad, the first website visit, the first sales email, the first demo, the first trial, the first onboarding call, and the first renewal conversation all shape how the buyer feels about the company.

That feeling matters.

If the buying process is slow, confusing, generic, or too sales-heavy, the customer starts forming a negative opinion before implementation even begins. If the process is useful, sharp, personal, and easy to navigate, the customer begins to trust the company before they sign.

This is especially true in crowded markets.

When many vendors claim similar AI features, integrations, dashboards, or automation benefits, the buying experience becomes a real differentiator. The buyer starts asking:

Who understands us fastest?

Who teaches us something useful?

Who makes the next step easy?

Who reduces internal risk?

Who helps us make a confident decision?

That is GTM as product.

Not just “how do we sell this?”

But “what experience are we designing for the buyer?”

The problem: most GTM motions are still too transactional

The average B2B buying journey is full of friction.

A buyer fills out a form and waits.

A rep asks questions the buyer already answered.

Marketing says one thing, sales says another.

The demo is generic.

The business case comes too late.

The handoff from sales to success feels messy.

The customer has to repeat the same context again and again.

From the company’s side, it may look like a funnel.

From the buyer’s side, it often feels like work.

That is the core problem.

Many GTM teams optimize for internal process, not customer experience. They measure stage progression, activity volume, MQLs, SQLs, meetings booked, pipeline created, and forecast accuracy. These metrics matter. But they do not always tell you whether the buyer journey feels useful, clear, and confidence-building.

This is a serious issue because buyers increasingly want more control. Gartner’s B2B buying journey research says 75% of B2B buyers prefer a rep-free sales experience. But Gartner also warns that self-service digital purchases are more likely to lead to purchase regret, which means the answer is not “remove humans.” The answer is to design the right mix of digital and human help.

That is where many companies get stuck.

They either over-automate and make the journey feel cold, or they over-rely on sales and make the journey feel slow.

The better path is to design GTM like a product.

What it means to design GTM like a product

Designing GTM like a product means treating your revenue motion as something that has users, features, friction points, data, releases, bugs, and a roadmap.

The users are not only customers. They are also the internal teams who operate the motion: SDRs, AEs, marketers, solutions engineers, customer success managers, partners, and RevOps.

A sales play is a feature.

A demo flow is a feature.

A pricing page is a feature.

An onboarding sequence is a feature.

A lead routing workflow is a feature.

A customer health alert is a feature.

A renewal business review is a feature.

Some of these features work.

Some are ignored.

Some confuse buyers.

Some slow deals down.

Some create expansion.

Some create noise.

The job of GTM leadership is to build the GTM product with the same seriousness that product leaders apply to software.

A strong GTM product has:

Clear customer segments
A defined journey from awareness to expansion
Useful digital experiences
Human touchpoints at the right moments
Tight handoffs between teams
Instrumentation across the funnel
Feedback loops from buyers and internal users
Regular releases, not annual overhauls
A roadmap tied to revenue outcomes

This is not just a metaphor. It is becoming an operating model.

RevPartners argues that GTM should not be managed as a static project. Their view is that GTM systems should be built in epics, improved in sprints, and adopted like internal products. That framing is useful because it pushes teams away from “launch and leave” and toward continuous improvement.

Why this matters now

There are three forces pushing GTM in this direction.

1. Buyers expect seamless omnichannel journeys

The buyer does not think in departments.

They do not care whether an experience is owned by demand gen, sales, product marketing, RevOps, customer success, or product. They only experience one company.

This is why omnichannel quality matters. McKinsey research on omnichannel B2B sales found that B2B customers regularly use ten or more channels to interact with suppliers. It also found that buyers are willing to spend large amounts through remote or online sales channels, with 35% willing to spend $500,000 or more in a single transaction and 77% willing to spend $50,000 or more.

This changes the role of GTM.

The website, product trial, demo environment, docs, ROI calculator, sales call, procurement process, and onboarding experience all need to feel connected. If they do not, the buyer loses trust.

2. AI makes continuous GTM iteration possible

In the past, improving GTM was slow.

You needed analysts to pull reports, managers to inspect calls, marketers to rewrite content, RevOps to update routing, sales leaders to retrain reps, and weeks or months to know if anything worked.

AI compresses that cycle.

Now teams can analyze call transcripts, summarize lost deals, personalize content, enrich accounts, detect friction, recommend next steps, and test messaging much faster. McKinsey’s B2B Pulse 2024 found that 19% of B2B sales forces are already implementing generative AI use cases, while another 23% are experimenting. The same research found that data-driven commercial teams blending personalized customer experiences with gen AI are 1.7 times more likely to increase market share than those that do not.

The opportunity is not simply “use AI in sales.”

The real opportunity is to use AI as part of the GTM product system: faster learning, better personalization, cleaner handoffs, sharper coaching, and more useful buyer experiences.

3. Product-led and sales-led motions are blending

Pure PLG and pure sales-led models are becoming less common at scale.

Many companies now need both.

They need the product to create awareness, usage, and bottom-up adoption. They also need sales to help larger accounts navigate risk, procurement, technical evaluation, security, ROI, and change management.

The challenge is that these motions often clash.

a16z’s Growth+Sales framework explains this well. The firm warns that layering sales too early can create two disconnected motions: one pitch for users who know the product, and another pitch for executives who do not. That creates complexity without synergy.

Designing GTM like a product helps solve this.

Instead of bolting sales onto product growth, you design the full journey from user adoption to enterprise expansion. You connect product signals to sales moments. You use engagement data to decide when human help is valuable. You make the sales motion feel like a continuation of the product experience, not an interruption.

The solution: build a GTM product operating system

A GTM product operating system has five parts.

1. Map the full customer journey

Start with the buyer, not the org chart.

Map every major step from first awareness to renewal and expansion:

First problem awareness
First brand touch
Website or content visit
Product trial or demo request
Qualification
Discovery
Demo or technical evaluation
Business case
Procurement
Onboarding
Activation
Adoption
Expansion
Renewal

Then ask one simple question at every step:

What does the buyer need to feel confident moving forward?

That question changes the GTM conversation.

Instead of asking, “What do we need to say?”

You ask, “What does the buyer need to understand, believe, compare, prove, or de-risk?”

That is a better design prompt.

2. Identify friction like a product manager

Product teams obsess over friction. GTM teams should do the same.

Look for moments where buyers slow down, disappear, repeat themselves, ask the same questions, or involve new stakeholders late in the process.

Common GTM friction points include:

Slow lead response
Weak routing
Generic outbound
Confusing pricing
Unclear product packaging
Poor demo customization
Late security review
Weak ROI case
No champion enablement
Messy sales-to-success handoff
Low product activation after purchase

These are not just “sales issues.” They are bugs in the GTM product.

And bugs should be prioritized, fixed, and measured.

3. Turn GTM plays into releases

Most companies create GTM plays as documents.

Better companies treat them as releases.

A release has an owner, target user, clear use case, enablement, success metrics, feedback loop, and update cycle.

For example, a new enterprise outbound play should not just be a sequence and a slide deck. It should include:

The target segment
The trigger events
The buyer personas
The insight being used
The core message
The proof points
The discovery guide
The demo path
The objection handling
The handoff rules
The success metrics
The review date

This is where GTM becomes more like software.

You do not expect version one to be perfect. You expect it to ship, generate data, and improve.

This is also how modern GTM engineering teams work. Clay’s write-up on its GTM engineering function says its internal GTM Engineering team runs in two-week sprints, triages automation and workflow requests, bundles them into releases, and ships twice a month with release notes.

That is the future direction: GTM teams shipping improvements, not just running campaigns.

4. Use product signals to trigger GTM motion

A product-like GTM motion should respond to behavior.

The best signal is often not a form fill. It is what the customer actually does.

Did usage spike?

Did a new team join?

Did a trial user invite colleagues?

Did an account hit a usage limit?

Did a customer adopt a high-value feature?

Did engagement drop?

Did an executive visit the pricing page?

Did a technical buyer return to security docs?

These signals should trigger useful GTM actions.

Not spam.

Not generic nurture.

Useful action.

A customer with growing usage may need expansion education.

A buyer reading security docs may need technical validation.

A user stuck during activation may need onboarding help.

A champion preparing for procurement may need an internal business case.

a16z highlights that in growth-plus-sales motions, product engagement data often reveals far more than backward-looking revenue metrics. Slack’s growth is used as an example: daily active usage inside an account can predict broader deployment and expansion.

That is a very product-like GTM idea.

Usage becomes the roadmap for sales and success.

5. Measure experience quality, not only pipeline

Pipeline is important. Revenue is important. Win rate is important.

But if you only measure financial output, you may miss the health of the journey that creates it.

A GTM-as-product model should measure both business outcomes and experience quality.

Useful metrics include:

Time to first response
Time to value
Lead-to-opportunity conversion
Trial-to-paid conversion
Demo-to-close conversion
Sales cycle length
Number of buyer handoffs
Number of repeated questions
Champion engagement
Product activation rate
Feature adoption
Stakeholder coverage
Content usage by stage
Deal slippage reason
Closed-lost reason quality
Post-sale activation
Expansion signal conversion
Customer effort score
Buyer satisfaction after demo or onboarding

The goal is not to drown the team in metrics.

The goal is to see the GTM journey clearly enough to improve it.

What this looks like in practice

Imagine a company selling a technical B2B platform.

The old GTM motion looks like this:

Marketing drives traffic.

A buyer fills out a form.

An SDR qualifies the buyer.

An AE runs discovery.

A solutions engineer joins later.

Procurement and security come in near the end.

Customer success learns about the deal after signature.

Onboarding begins with limited context.

The product-designed GTM motion looks different.

Marketing helps the buyer diagnose the problem before a call.

The website routes buyers by use case, maturity, and segment.

The demo request captures useful context.

The SDR has account intelligence ready before outreach.

The AE uses discovery to create a useful point of view, not just qualify.

The demo is tailored to the buyer’s architecture and business priority.

Security and procurement assets are introduced early.

The champion receives internal enablement materials.

Customer success sees the full pre-sale context before kickoff.

Product usage signals guide onboarding and expansion.

The second version feels smoother because it was designed.

That is the whole point.

The Stripe lesson: make the buying journey useful

One of the best ideas from the transcript that inspired this article was the Stripe whiteboarding example.

Instead of treating discovery as a one-way interrogation, the team used a whiteboarding session to map the customer’s payments architecture. Stripe still learned what it needed to learn: stack, pain points, competitors, value opportunities, and technical complexity. But the customer also received something useful: a clearer view of their own system.

That is GTM-as-product in one scene.

The buyer journey should create value even before the buyer purchases.

The best GTM teams teach, diagnose, benchmark, simplify, and de-risk. They do not only pitch.

This is especially powerful for enterprise buyers because the sale is not just about desire. It is about confidence. The buyer needs to feel they can defend the decision internally.

A great GTM motion helps them do that.

The role of RevOps, product marketing, and GTM engineering

Designing GTM like a product requires new ownership.

RevOps becomes less of a ticket queue and more of a product operations team. Product marketing becomes less of a launch factory and more of a journey design function. Sales leadership becomes less focused on activity management and more focused on buyer progression. Customer success becomes part of growth, not just retention.

And increasingly, GTM engineering becomes the build layer.

This is already visible in the market. Clay describes GTM Engineering as sitting at the core of its go-to-market motion, operating like a product engineering team with sprints, version control, and release notes. Akeneo’s GTM Engineer role description also shows how this role is being formalized, with responsibilities such as mapping the GTM stack, identifying manual bottlenecks, automating lead routing and account research, and measuring impact through metrics like time-to-first-touch.

That is a sign of where GTM is heading.

The revenue team of the future will not only hire more sellers and marketers. It will also hire builders who can turn GTM ideas into working systems.

A simple framework: the GTM Product Loop

Here is an easy way to apply this mindset.

Step 1: Diagnose

Pick one part of the buyer journey.

For example:

Inbound conversion
Enterprise discovery
Trial activation
Technical evaluation
Champion enablement
Sales-to-success handoff
Renewal and expansion

Map the current process. Look at the data. Watch calls. Review emails. Interview reps and customers. Find the friction.

Step 2: Design

Define the better experience.

Ask:

What should the buyer feel at this stage?
What information do they need?
What risk are they trying to reduce?
What proof would help?
What should be self-serve?
Where should a human step in?
What should happen next?

Step 3: Ship

Build the smallest useful version.

That could be a new page, workflow, demo format, lifecycle email, sales play, onboarding flow, AI agent, ROI calculator, or internal Slack alert.

Do not wait for perfection. Ship the first useful version.

Step 4: Measure

Track both revenue and experience metrics.

Did conversion improve?

Did the cycle shorten?

Did buyers ask fewer repeated questions?

Did reps use the play?

Did activation improve?

Did more champions share materials internally?

Step 5: Iterate

Review what worked. Remove what did not. Improve the play. Train the team. Ship the next version.

This loop is simple, but it changes the culture.

GTM becomes less opinion-driven and more evidence-driven.

What GTM leaders should do next

The best first step is not a massive transformation.

Start with one high-impact journey.

For many companies, the best starting point is the demo request to first meeting journey. It is visible, measurable, and often full of friction.

Ask your team:

What happens when a high-fit buyer raises their hand?

How fast do we respond?

How much context do we collect?

How much research happens manually?

Does the first call feel useful to the buyer?

Do we teach them something?

Do we route them correctly?

Do we make the next step easy?

Then redesign that journey like a product.

Create version one.

Ship it.

Measure it.

Improve it.

Once the team sees the value, apply the same method to outbound, onboarding, expansion, and renewal.

The future: GTM teams will ship experiences

The future of GTM will be more technical, more cross-functional, and more customer-led.

The best teams will not simply run more campaigns. They will ship better experiences.

They will design the buying journey.

They will instrument the revenue engine.

They will use AI to learn faster.

They will combine self-service and human guidance.

They will turn product usage into GTM action.

They will treat internal teams as users.

They will keep improving the system every month.

This is good news.

It means GTM can become more useful to buyers, not more aggressive. It means sellers can spend more time helping customers and less time fighting broken workflows. It means marketing can move closer to revenue and product. It means customer success can become a growth engine. It means RevOps can become a strategic product function.

The companies that win will not be the ones that shout the loudest.

They will be the ones that make buying feel clear, helpful, and low-risk.

That is what happens when you design GTM like a product.

And in a market where products are easier to build and harder to differentiate, the experience around the product may become one of your strongest advantages.

Open Source Stars Are Not Revenue, You Need a Commercial Bridge

Peter Strauss — Fri, 17 Apr 2026 11:40:08 +0000

Open source companies are rich in attention and poor in monetization.

The repo grows. Stars go up. Contributors show up. The community gets louder.

Everyone feels like momentum is real, and in one sense, it is. But if that attention never crosses the bridge into paid value, the business can stay strangely fragile for a long time.

I think this is one of the most common GTM blind spots in open source. Founders assume growth in the community automatically means growth in the company. Sometimes it does. A lot of the time, it just means the market likes the project more than it understands the commercial reason to pay for it.

That is the trap.

The market says community matters — but not in the way people think

The Linux Foundation’s 2025 State of Commercial Open Source report is one of the clearest recent signals here. It shows that commercial open source companies consistently outperform closed-source peers in valuations, funding speed, and liquidity outcomes, especially in infrastructure software. It also says something even more important: strong community health is closely linked to higher company valuations.

That sounds bullish for open source, and it is.

But it is very easy to hear the wrong lesson.

The right lesson is not:
“community equals revenue.”

The right lesson is:
“community creates leverage — if the company knows how to convert community value into commercial value.”

That is a much harder and more useful truth.

Ubuntu’s 2025 global open source report helps sharpen this. It says 83% of organizations see open source as valuable to their future, and 46% reported increased business value from open source year over year. At the same time, the same research warns that adoption is outpacing maturity, especially in governance and operational discipline.

That is the pattern I keep seeing.

What are the top 1% of GTM operators doing differently? We deconstruct their playbooks every week. Don’t miss the next one—subscribe at GTM.NEWS.

Open source gets distribution first.
The business model comes later.
And if “later” lasts too long, the company gets trapped in a weird middle ground: popular enough to attract users, but too vague commercially to convert them cleanly.

The harsh truth

Usage is not monetization.

Community is not monetization.

Stars are definitely not monetization.

Those things can support a business. They do not automatically become one.

A lot of founders avoid this because the transition feels uncomfortable. The community likes the project partly because it feels open, accessible, and developer-first. The moment the company talks more directly about money, support, enterprise packaging, or commercial boundaries, it worries about backlash.

That fear is real.

But the worse risk is building a beloved project with no clear economic engine.

Because once that happens, the company starts making bad GTM decisions:

vague enterprise pages
weak upgrade paths
unclear feature gating
random sales outreach
awkward “contact us” monetization
community growth treated like a revenue strategy

That is not a bridge.
That is wishful thinking.

My rule: identify the moment free use becomes expensive

This is the cleanest commercial frame I know for open source GTM.

Do not start with:
“What can we charge for?”

Start with:
When does free usage stop being enough for a serious team?

That is where the commercial bridge lives.

Usually the trigger shows up in one of five places:

governance
reliability
support
scale
security or compliance

The open source product wins the developer.
The commercial product wins the organization.

That is the distinction.

The practical fix: build a three-step commercial bridge

If I were helping an open source company clean up its GTM, this is the system I would build.

Step 1: Define the free-to-paid trigger clearly

This is not a pricing exercise first.
It is an operating transition.

Ask:

when does the tool become business-critical?
when does the team need controls?
when does uptime or support start mattering?
when does security review become real?
when does “we can manage this ourselves” stop being true?

If you cannot point to that transition cleanly, the sales motion will stay fuzzy.

Step 2: Package the paid layer around organizational pain

This is where a lot of companies get too clever and not useful enough.

Do not sell vague “enterprise value.”

Sell the things that remove pain for the organization:

SSO / access control
auditability
support SLAs
compliance posture
policy enforcement
deployment flexibility
admin and governance tooling
faster implementation or migration help

The developer might love the open source project.
The buyer pays when the company makes organizational pain smaller.

Step 3: Route community signals into product-qualified accounts

Community should not feed a vanity dashboard.
It should feed the commercial motion.

I would track:

repeated usage from the same company domains
contributors from target accounts
GitHub actions or repo activity that suggest production use
docs traffic from likely enterprise environments
community questions that signal rollout, governance, or scale pain

That is how open source attention becomes GTM intelligence.

A worked example

Imagine an open source observability tool.

The weak monetization path says:

free repo
lots of stars
community Slack
vague enterprise page
“contact sales” buried in the nav

The stronger path says:

free core remains genuinely useful
clear page explaining when teams outgrow self-managed use
enterprise product built around access control, support, auditability, and scale
proof showing what changes when the tool becomes critical infrastructure
community and product signals routed into outbound or lifecycle plays

Now the company is not trying to “monetize the community” in some vague sense.

It is helping serious users recognize when the commercial layer makes sense.

That is much cleaner.

What to measure

I would track:

percentage of community or OSS users converting to team or enterprise use
time from first repo interaction to commercial inquiry
top free-to-paid trigger by segment
domain concentration in product usage and community activity
expansion rate among accounts that started in OSS

Those numbers tell you whether the bridge exists or whether the company is still standing on one side hoping money appears on the other.

My practical take

One of the more useful truths in open source GTM is that community is not the finish line.

It is the beginning of leverage.

The business wins when it can preserve community energy while giving organizations a very clear reason to pay when the stakes get higher.

That means:

know when free stops being enough
package around organizational pain
route OSS signals into GTM
and stop treating stars like a business model

Because open source can absolutely create great companies.

But only when the bridge from project love to commercial value is built on purpose.

Time-to-First-Success Is Your Real Acquisition Funnel

Peter Strauss — Thu, 16 Apr 2026 09:04:38 +0000

A lot of devtool companies think they have an acquisition problem when they really have an activation problem. They fight for the click, celebrate the signup, and then quietly lose the user in the first 15 minutes.

That is the trap.

The market calls it “top of funnel,” but the builder’s version is simpler: if the developer does not reach a real first win fast enough, you did not really acquire them.

I think this is one of the biggest GTM mistakes in developer businesses because it hides inside decent-looking growth metrics. Traffic can be up. Signups can look healthy. Docs can get views. Community can be active. And still the business can feel weirdly sticky and slower to grow than it should, because the product is asking the user to do too much work before they feel any payoff.

That is not just a product issue.

That is a GTM issue.

The data already points in one direction

The strongest recent developer-adoption research says the same thing very plainly: adoption is not mainly a content problem. It is a product-experience problem.

In Instruqt’s State of Developer Adoption 2025, developer GTM teams still rely heavily on written documentation, but hands-on, real-world training is ranked as the most effective way to drive adoption at 42.6%, ahead of step-by-step documentation at 39%. Yet fewer than one-third of organizations are actively investing in interactive labs today. The same research says 57.3% of organizations track product usage as their primary adoption metric, and nearly 60% report that it takes one to three months for developers to fully adopt new software.

That is a huge clue.

If the market says hands-on experience is what actually drives adoption, but most teams still lean hardest on static docs and then wait one to three months for usage to stabilize, the gap is not in awareness. The gap is in how quickly the product helps the user succeed.

Atlassian’s 2025 DevEx work says the same thing from a different angle. In its 2025 State of Developer Experience report, almost all developers say AI is saving them time, but 50% still lose 10+ hours a week to non-coding work and 90% lose 6+ hours or more. Their biggest friction points are finding information, adapting new technology, and context switching between tools. Atlassian also says developers spend only 16% of their time coding, which is a really useful reminder that the thing slowing adoption is not usually the code itself. It is the friction around the code.

That matters a lot for devtools founders.

Because if your product asks the user to search, interpret, adapt, switch, configure, and guess before they get a real success moment, you are not just creating friction. You are making the acquisition more expensive than your dashboard admits.

The harsh truth

A signup is not proof of demand.

A signup is proof of curiosity.

That sounds obvious.
A lot of companies still operate like it is the same thing.

Curiosity signs up because:

the idea sounds promising
the docs look interesting
the product got shared on X or GitHub
the buyer wants to compare options
the developer wants to test whether this could save time later

Demand shows up when the developer gets a working result and thinks:

“Okay, this is actually useful.”

That is a very different moment.

And it usually happens much later than the marketing team wants to believe.

My rule: acquisition ends at first success, not first signup

This is the cleanest operating rule I know for developer GTM.

Do not ask:
How many signups did we get?

Ask:
How many users reached a meaningful first success quickly enough to want the second step?

That immediately changes what you build, what you measure, and where you spend time.

Because once first success becomes the metric, all the usual debates start looking different.

You stop obsessing over:

homepage tweaks
shallow lead counts
vanity community growth
generic doc traffic

And you start obsessing over:

how long setup takes
where users get stuck
what information they search for first
how many steps it takes to get one real working outcome
how quickly the user can see the product in their own reality

That is a much better GTM lens for developer businesses.

Why first success matters so much

There are three reasons this lever is stronger than it looks.

1. It collapses the gap between product and GTM

For most B2B categories, marketing and product can still pretend to be separate functions for a while.

Developer products do not have that luxury.

If the developer cannot understand, test, and validate the value quickly, the business does not just have a product problem. It has a conversion problem, a trust problem, and a retention problem all at the same time.

2. It reduces how much selling has to happen later

When users reach a real first success quickly, a lot of downstream GTM gets easier:

docs feel more useful
support load drops
community explanations get cleaner
team invites happen more naturally
enterprise conversations start from evidence, not theory

That is a big deal.

The easier the first win is to reach, the less human effort you need to “sell” the product later.

Enjoyed this deep dive? Get more actionable Go-To-Market insights delivered straight to your inbox. Join the community and sign up at GTM.NEWS today.

3. It creates a cleaner signal for who is truly activated

Instruqt’s data is useful here again. If most teams are using product usage as the primary adoption metric, then the smarter question is not “did they use the product?” It is “did they reach the first behavior that predicts meaningful usage?” That is a much sharper activation signal than simply counting accounts created.

The practical fix: build a first-15-minutes activation path

If I were fixing this for a developer product this week, I would not start by writing more docs.

I would start by designing the shortest path to one undeniable win.

Here is the framework I would use.

Step 1: Define the first success moment

This is the most important question in the whole article.

What is the first moment where the user can honestly say:
“It works.”

Not “I understand the product.”
Not “the dashboard loaded.”
Not “the environment is configured.”

A real win.

Examples:

first successful API call
first live deployment
first test generated and passing
first working integration with an existing tool
first useful alert or automation firing in production or staging
first code issue caught or fixed in a realistic workflow

That moment needs to be concrete, visible, and meaningful.

Step 2: Strip the path down to the minimum useful steps

Once you know the first win, remove everything that is not necessary to get there.

I would map the current path like this:

signup
verify email
create workspace
choose use case
install package
connect repo
configure permissions
read docs
write code
test output
debug setup
finally see result

That is already too much for many products.

The better question is:
What can we pre-configure, automate, sandbox, template, or defer until after the first win?

This is where a lot of adoption gets rescued.

Step 3: Create one golden path per ICP

Do not make one generic onboarding path for “developers.”

That is lazy and usually weak.

Create one shortest-path experience for each core use case or buyer type.

For example:

solo developer evaluating in a sandbox
startup engineer integrating with a real repo
enterprise evaluator testing security and workflow fit
DevOps lead validating rollout across environments

Different users need different first wins.
Treating them the same slows everyone down.

Step 4: Build one fallback path for failure

This is one of the little tricks more experienced operators use.

Most onboarding paths are designed for success.
A lot of developer trust is actually won in failure.

When setup breaks, the user should not have to improvise the next move.

Give them:

one fast troubleshooting page
one known-good sample project
one way to test in a sandbox
one clear “here is where people usually get stuck” guide
one fast route to support or community help

That makes the product feel more mature immediately.

Step 5: Measure time-to-first-success directly

I would track:

median time from signup to first success
percentage of users reaching first success in 15 minutes, 1 hour, and 24 hours
top drop-off steps before first success
most common setup failures
second-step behavior after first success

That last one matters a lot.

Because a first success that does not lead to deeper usage might still be too shallow. You want the first success to create momentum, not just a temporary smile.

A worked example

Let’s say you run a developer observability product.

The weak GTM story says:

drive traffic to docs
offer a free trial
let users connect their stack
hope they reach value after instrumentation

That sounds normal.
It is also a little cruel.

The better version says:

pick one high-pain use case, like “find the root cause of a slow endpoint”
give the user a sample environment or staged sandbox
show one issue being found and explained in under 15 minutes
then guide them into connecting their real environment

Now the first win comes before the heavy lift.

That changes the emotional arc completely.

Instead of:
“this looks complicated”

the user thinks:
“okay, this helps — now I’m willing to do the setup.”

That is a much stronger growth motion.

Where AI helps

This is one of the best areas to use AI productively.

Use AI to:

identify where users get stuck in docs and onboarding
cluster failed setup flows
personalize the first-path instructions by stack
generate better in-product troubleshooting guidance
summarize the fastest route to success based on user context

But the key is the same as everywhere else:
AI should reduce friction, not add another layer of vague possibility.

A bloated AI assistant inside onboarding does not save you if the path to first value is still too long.

What I would do this quarter

I would run a 30-day activation audit.

Watch 10 real users try to reach first success.
Time every step.
Mark every point where they search, switch tools, or ask, “What do I do now?”
Cut at least one major step before the first win.
Build one golden path and one fallback path.
Make time-to-first-success a company-level GTM metric, not just a product metric.

That is a very practical way to turn adoption into a growth lever.

My practical take

One of the more useful truths in developer GTM is that product acquisition is often won or lost after the signup.

That is the part many teams still underweight.

They spend heavily to create interest, then quietly ask the developer to do too much work before the product proves itself. In a world where developers are already overloaded, already switching tools, and already losing time to friction, that is a very expensive mistake.

The good news is that this is fixable.

You do not need more hype.
You need a cleaner first win.

And once the first win gets faster, a lot of the rest of GTM starts working better too:

activation improves
support gets lighter
sales gets cleaner signals
community becomes more useful
and the product starts feeling easier to believe in

That is what a real acquisition funnel looks like for developer products.

It does not end at signup.

It ends when the user succeeds.

Stop Building AI Features Nobody Asked For

Peter Strauss — Wed, 15 Apr 2026 08:40:03 +0000

The easiest way to waste six months in 2026 is to build an AI feature that gets a great demo reaction and a weak buying reaction.

People will tell you it’s cool.

They will not tell you it is urgent.

And unless you learn to hear the difference early, you can burn a lot of engineering time polishing curiosity instead of solving pain.

I think this is one of the biggest traps for builders right now, especially developer founders. AI makes prototyping fast, which feels like an advantage. It is an advantage. But it also makes it dangerously easy to ship the wrong thing at high speed. When build cost drops, discipline has to go up.

The market is rewarding faster validation, not just faster building

McKinsey’s latest work on AI-first venture building says AI is materially compressing venture timelines, reducing time to validation, and raising output per person and per dollar. It also makes a very important distinction that I think a lot of founders miss: the winners are not just using AI to generate more ideas or code faster. They are validating more ideas earlier and scaling the winners sooner.

That matters because most early-stage product mistakes are not engineering mistakes. They are market mistakes.

The classic version of this is already familiar. In CB Insights’ long-running startup failure analysis, lack of market need remains one of the biggest reasons companies fail. AI does not remove that risk. It actually makes it easier to hide for a while, because you can produce a lot of convincing surface area before you ever prove someone will pay.

That is the trap.

The harsh truth builders need to hear

A lot of AI features are built because the founder can imagine the future, not because the customer is desperate in the present.

That sounds harsh. It is also useful.

There are usually three reasons teams build AI features too early:

the market expects an AI story
the prototype looks impressive fast
the founder wants to keep up with competitors

All three are understandable. None of them is evidence of demand.

For a builder, that is one of the harder mindset shifts: being able to build something quickly is not a reason to build it now. The real question is whether the workflow is painful enough, frequent enough, and expensive enough that a customer will change behavior or budget for it.

If the answer is vague, you are probably building a feature for applause.

My rule: sell the workflow before you automate the workflow

This is the cleanest principle I know for avoiding AI feature waste.

Do not ask:
Can we build this?

Ask:
Can we sell the outcome this workflow would create?

That subtle change does a lot of work. It forces you to think in commercial terms before you get seduced by technical possibility.

For developer tools, the workflow usually matters more than the model. Customers are not paying for “AI.” They are paying for:

faster code review
safer releases
easier API integration
less debugging
better test coverage
faster onboarding for new engineers
fewer support escalations

That is where the demand lives.

The practical fix: run a 5-customer AI validation sprint

If I were running a devtools startup right now, this is the exact process I would use before shipping a serious AI feature.

Step 1: Name one painful workflow

Not a category.
Not a vision deck.
One painful workflow.

Examples:

generating test cases for flaky endpoints
writing migration notes during releases
triaging production incidents
summarizing code-review feedback for junior developers
creating API integration snippets from messy internal systems

Good workflows have three traits:

they happen often
they are expensive or annoying
they already make someone feel real pain

Step 2: Write the offer before writing the feature

This is where most teams skip the hard part.

Write one page that says:

who this is for
what painful workflow it fixes
what measurable outcome improves
how quickly value should show up
what it costs

If you cannot explain the commercial value in plain language, the feature is still too fuzzy.

Step 3: Pre-sell to five target users

Do not ask, “Would you use this?”
That question creates fake optimism.

Ask for one of these instead:

a paid pilot
a design partnership with defined success criteria
access to real workflow data
a commitment to trial the feature when it reaches a specific outcome

The goal is not broad feedback.
The goal is proof of seriousness.

Step 4: Deliver manually or semi-manually first

This is the part builders hate and smart operators love.

If the workflow matters, do some of it manually first. Use prompt chains, scripts, internal tools, or even human-in-the-loop delivery. You will learn:

where context breaks
what “good enough” actually means
where the user still wants control
which output format people trust
what edge cases kill the experience

That learning is worth a lot more than an elegant prototype built in isolation.

Step 5: Productize only what repeats

Once you see the same workflow, correction pattern, and desired outcome repeating across users, then build.

Not before.

Build the repeated value.
Not the imagined value.

A worked example

Imagine a small startup building for backend teams. The founder wants to launch an AI feature that “explains pull requests automatically.” It sounds useful. Maybe even obviously useful. But that is still too abstract.

The better move is to narrow it.

Pick one workflow:
help engineering managers review large PRs faster without missing risk

Now pre-sell that outcome:

reduce review time on large PRs
surface risky file changes
summarize architectural tradeoffs
generate a comment-ready explanation the manager can trust

Then run five pilots.
Maybe two customers care mostly about security-sensitive diffs.
Maybe one team wants onboarding context for newer reviewers.
Maybe another team does not need summaries at all — they need change-risk ranking.

Now the feature has shape.
Not because the founder guessed better.
Because the market taught the product what to become.

Where AI really helps in this process

This is the optimistic part.

AI is fantastic for speeding up validation work if you use it correctly. McKinsey is right that AI can help teams generate, test, and refine ideas faster, run mini marketing experiments, and pressure-test concepts before full commitment. That does not replace customer conversations. It makes the early learning loop cheaper and faster.

Use AI to:

map competing products and positioning
generate landing page variants for smoke tests
synthesize interview notes
build lightweight prototypes for pilot users
summarize repeated objections
cluster workflow patterns across early testers

That is real leverage.

What I would not do is confuse internal enthusiasm with external proof.

My practical take

One of the quiet business truths in the AI era is that it is now easier than ever to overbuild.

That means good founders need a stronger filter, not just faster hands.

The filter is simple:

is the workflow painful?
is the buyer specific?
is the outcome measurable?
has someone serious committed?
did the same need repeat across multiple real users?

If the answer is no, slow down.
If the answer is yes, then build aggressively.

Because the real edge is not shipping more AI features.

It is shipping fewer, better ones — the ones customers were already trying to buy before the code was finished.