“Your new business cost of sale contribution is 30 % of the total deal size. That's insane. How do you fix that without pissing off the sales team? That's a big question.”
Product
Where they agree
-
Users will increasingly stop logging into application interfaces and instead work through LLMs and agentic tools connected to back-end software.
4 independent voices · 2 shows1 new this month
On [Un]Churned, Brady Bluhm said that after using Staircase's MCP he expects people won't need to log into product UIs within about two years, because LLMs improve faster than other software.
4 sources
Data creates the most value when it is delivered at the workflow level through a headless AI interface such as an MCP server, not as a standalone dashboard. Listen
Ann says Crunchbase launched its MCP server about a month before the recording and that the value lies in bringing data sources together through an AI interface that sits inside the seller's workflow. She says the choice of front-end AI tool, such as ChatGPT, Gemini or Grok, does not matter.
“it's about how you seamlessly bring together the data sources through the AI interface to deliver real value.”
Listen to the episode Episode Product Link to this Report a problem
Customers can use Gainsight through external agentic tools such as ChatGPT, Gemini or Claude without logging into Gainsight. Listen
Chuck Ganapathi says Gainsight launched its MCP interface about a month before Pulse, and all its products now have one. He says this lets customers work in their preferred agentic tool and use Gainsight without ever having to log into it, and that the Gainsight CLI lets admins configure the product through coding agents.
“you can use Gainsight without ever having to log into Gainsight”
Listen to the episode Episode Product Link to this Report a problem
The traditional application UI will eventually fade, with LLMs becoming the main workspace regardless of the back-end application. Listen
Diane Wu says that in the old world CSMs used multiple tabs and tools to get the context they need, and she expects this to go away. She describes the LLM as the new workspace, with the interface being natural language rather than visual, at least today. She adds that this might change very quickly in the future.
“I'm a believer of the traditional application UI is going to eventually fade and go away and LLMS will become the new workspace”
Listen to the episode Episode Product Link to this Report a problem
Brady Bluhm predicts that in about two years people will not need to log into product UIs, because LLMs are improving faster than other software. Listen
Brady Bluhm says he had a product manager's existential moment after playing with Staircase's MCP and asking why anyone would log into his product in a year and a half or two years. He expects that change because LLMs themselves are improving faster than other software. He still builds for the UI today because not everyone works in LLMs all the time.
“in two years from now, I think that's going to change because the LLMS themselves evolved so much faster than any other product will too”
Listen to the episode Episode Product Link to this Report a problem
-
Embedding engineers with customers to build customer-specific solutions, then productizing the ones that recur, is an effective way to build product.
4 independent voices · 2 shows1 new this month
On [Un]Churned, Diego Ballona said Intercom built a Slack support feature for one customer in weeks, off-roadmap, then productized it to general availability in about three months.
7 sources
Atlas turns recurring human-handled escalations into agent capabilities through forward deployed engineers who ship them in roughly two-week sprints. Listen
Grant Clarke says Atlas records what reps do outside the agent's handoffs and classifies those actions into buckets. Forward deployed engineers, product managers and business analysts sit 'in the boat' with renewal managers to monitor this. When a category of escalation recurs multiple times, it becomes a product requirement. The FDE team develops it in maybe two weeks, tests it for a few weeks, and puts it back into Atlas.
“The FDE team can sprint, develop that in maybe two weeks, run a few weeks of testing, and then it's right back into Atlas to handle the next customer issue that comes up.”
Listen to the episode Episode Product Link to this Report a problem
Rick suggests building customer-specific applications alongside the core product so a company can say yes to edge-case requirements, with forward-deployed engineering teams as a way to do it. Listen
Rick says a core offering may handle around 90% of what customers need, and that the remaining edge cases can be handled by building applications that complement the core product. He says this is more possible now, but that it adds complexity because forward-deployed engineering teams must work with core engineering. He says each organization should decide which things it will not build into the core product but will still say yes to.
“what are the things that we're not going to build into our core offering? But we should be able to say yes to”
Listen to the episode Episode Product Link to this Report a problem
Implementation is moving out of customer success and into the product org in some portfolio companies. Listen
Cassie says she is seeing a notable organizational change in portfolio companies: implementation, previously in the chief customer officer or post-sales lane, is moving into product. Companies view getting customers up and running as a product opportunity, and the best organizations productize what they learn from forward-deployed work immediately.
“implementation in many places is being moved out of the chief customer officer lane or the post-sales lane and into product”
Listen to the episode Episode Product Link to this Report a problem
Forward-deployed engineers only form a true model when implementation work feeds a feedback loop into product. Listen
A host says many AI companies have forward-deployed engineers but no plumbing connecting them to product, so the work is just implementation. He says the true FDE model is one where that work feeds back into what gets built, which is what made the Palantir model special. Cassie agrees, saying Primary has discussed the Palantir model internally and that Palantir built product off it rather than just selling services.
“The whole FTE concept was it was going to help Palantir figure out what to build and that feedback loop is what was so special about the whole model”
Listen to the episode Episode Product Link to this Report a problem
Diego describes a split in which FDE builds early prototypes for specific customers and a core product team later productizes them. Listen
He said FDE works on early prototypes with specific customers. Once a product becomes a big part of the platform's infrastructure and needs more investment, a core product team takes ownership and productizes it for all customers.
“But at some point, it makes sense for a core product team to own the product because it becomes a big part of like our infrastructure of our platform.”
Listen to the episode Episode Product Link to this Report a problem
A Slack channel support feature began as a rapid prototype for one customer and was productized within about three months. Listen
A customer had a large share of its support volume on Slack, which Fin did not support at the time. Engineers sat with the customer's head of support, and an engineer estimated a version could be built in two to three weeks. Intercom built it for that customer despite it not being on the roadmap, and because demand was validated, it was productized into a general availability product in about three months.
“we actually decided to invest in that because we validated demand.”
Listen to the episode Episode Product Link to this Report a problem
Engineers sitting with customers feel the pain first hand, which Diego says speeds up iteration and ownership. Listen
Diego said this is different from aggregated research or metrics, which he called very valuable but slower to act on. He said the FDE motion has led Intercom to build a better product for all customers and better internal tooling for its go-to-market team.
“when you get engineers sitting with customers directly, they feel the pain first hand.”
Listen to the episode Episode Product Link to this Report a problem
-
AI making features cheaper to build does not mean shipping more of them, because more features lead to bloat and incoherent products.
4 independent voices · 3 shows2 new this month
On Topline, Steve Cox cited a statistic that people use about 25% of their software tools, arguing more features create bloat rather than a better system.
4 sources
Product sense is ruthless prioritization, not building more features Listen
Dan Lee said it is easy to build a ton of features, so the hard part is knowing what is important. Nooks lives by a do more with less value, and he described its approach as rigorously evaluating options against each other and setting clear north-star metrics and leading indicators.
“we can do anything but not everything.”
Listen to the episode Episode Product Link to this Report a problem
Competitors racing to ship the ~100 features needed to run a GTM team often end up with 'Frankenstein' apps that reps can't use. Listen
A host had observed that GTM platforms bolt features onto a left-hand menu without connected workflows. Keith agreed that everyone is racing to the roughly 100 features required to run a go-to-market team. He said making them performant and coherent together is really hard, and many players produce apps that in theory prospect, forecast and hold a CRM data model but aren't usable by a rep.
“create this Frankenstein app. You know, with a hundred features that in theory could prospect, in theory could forecast, in theory has a CRM data model, but is not a thing that a rep can use.”
Listen to the episode Episode Product Link to this Report a problem
Steve Cox cites an old statistic that most people use about 25% of the software tools they have, and says more features can lead to feature bloat rather than a better system. Listen
He says companies can keep releasing features every day, but adoption is the constraint, which is part of why AI has not yet delivered ROI. He argues that adoption needs to be designed for rather than assumed.
“one of the old stats was like most people use about 25% of all the software tools that they have”
Listen to the episode Episode Product Link to this Report a problem
AI making features faster to build does not mean a product should ship more features. Listen
He says that shipping more features adds cost, as products get bloated and features may not work together well or be considered enough. He says that for Linear the aim has been the right features built in a streamlined way rather than the most features, which means the product is simpler and users spend less time setting things up.
“if AI makes building things faster, it doesn't mean you should be like, Shipping more stuff necessarily”
Listen to the episode Episode Product Link to this Report a problem
-
Structured batches of direct customer conversations are an effective way to find or test product-market fit.
5 independent voices · 4 shows2 new this month
On 20VC, Alex Mashrabov said all eight creative directors Higgsfield interviewed named camera control, which became the product that took it from about $1M to $20M ARR in three months.
6 sources
To settle whether slow growth is a product problem or a go-to-market problem, Vercel ran its PM and lead engineer through 10 back-to-back customer conversations, and concluded it lacked full enterprise product-market fit. Listen
Grosser said no one has invented a test for product-market fit, so the question of product versus go-to-market keeps coming up. At Vercel she picked 10 large existing enterprise customers that used Vercel but not yet in front of their main site, and had the product manager and lead engineer hear all 10 in a row to build pattern recognition. Afterwards everyone agreed there were product gaps to close before the product would be much more easily sellable. She noted that some enterprises still buy before full fit, because a visionary buyer will always work through the pain.
“So we're like, great, let's go get 10 of those. Let's get the product manager, lead engineer, and let's run them through conversations with all 10 in a row, so they can get pattern recognition.”
Listen to the episode Episode Product Link to this Report a problem
Interviewing eight creative directors surfaced one consistent gap, camera control, which became Higgsfield's breakthrough product. Listen
After the pivot, Higgsfield asked eight creative directors what was missing from AI video, and every one of them said camera control, which they called essential to storytelling. The product launched on March 31 and Mashrabov describes product-market fit as immediate. He says VFX and camera control took Higgsfield from roughly $1M to $20M ARR in about the first three months.
“We spoke to eight creative directors about their experience with AI and what's simply missing. Everyone told us that camera control does not exist in AI.”
Listen to the episode Episode Product Link to this Report a problem
He planned 30 CFO conversations over three months as QuotaPath's CEO, as part of product discovery. Listen
He said he told his board in July that he would hold 30 CFO conversations in three months, using a road show, dinners and Q and A sessions with guests such as Pablo Dominguez and Kyle Norton. He said he would record the conversations with AI to find patterns afterwards. He said changing buyer behaviour made listening more important than before.
“I told the board in July's board meeting, I am going to have 30 CFO conversations over the next three months.”
Listen to the episode Episode Product Link to this Report a problem
Bhatt credits Robinhood's breakthrough against entrenched brokers to insight into how people would use technology plus systematic customer conversations feeding product development. Listen
He calls mass-market consumer product-market fit extraordinarily difficult, especially when many talented, well-resourced incumbents already serve the market. Robinhood broke through by pairing its view of how people would use mobile with systematic processes for understanding customer needs and flowing them into what it built.
“through pretty systematic ways of talking to customers and understanding what their needs are, and, you know, flowing those into the product development.”
Listen to the episode Episode Product Link to this Report a problem
In pre-product discovery at Okta, Kerrest set himself a quota of 18 net-new IT professional conversations a month and tracked each one on a color-coded sheet. Listen
Starting around August 2009, for four months, Kerrest talked to IT professionals about their problems and whether they would use or buy a solution, and showed them drawings, documents and pictures. He tracked each name and contact date in green, yellow or red, and says he missed his number in some months. He cites Peter Thiel's Zero to One and Steve Blank's Four Steps to the Epiphany as the basis for the approach.
“I had a monthly plan where I had to go talk to 18 net new IT professionals and just talk to them and say, Hey, what kind of problems do you have? Do you have this problem? Would you use this? Would you buy this?”
Listen to the episode Episode Product Link to this Report a problem
Market validation can be run as a structured tour of about 30 prospects, with a mock-up-driven MVP refined between visits. Listen
Mike said LinkedIn used a process taught by Frank Robinson in which a product manager, an engineer and a sales or marketing person travelled in waves of five or six prospects and changed mock-ups back at the hotel for the next day. The aim was to exit with 10 or 15 prospects contractually committing to buy at a stated price if the product was built as described. He said the team spoke to 30 prospective clients in total.
“You go off and you speak to 30 prospective clients.”
Listen to the episode Episode Product Link to this Report a problem
Ranked by how many independent voices make each point and how specific their evidence is. Co-hosts of a show count as one voice, and a point needs at least two shows to appear here.
Where they split
Users will increasingly stop logging into application interfaces and instead work through LLMs and agentic tools connected to back-end software.
said Ann Davis (Revenue Builders), Chuck Ganapathi ([Un]Churned), Diane Wu ([Un]Churned), Brady Bluhm ([Un]Churned)
4 sources
Data creates the most value when it is delivered at the workflow level through a headless AI interface such as an MCP server, not as a standalone dashboard. Listen
Ann says Crunchbase launched its MCP server about a month before the recording and that the value lies in bringing data sources together through an AI interface that sits inside the seller's workflow. She says the choice of front-end AI tool, such as ChatGPT, Gemini or Grok, does not matter.
“it's about how you seamlessly bring together the data sources through the AI interface to deliver real value.”
Listen to the episode Episode Product Link to this Report a problem
Customers can use Gainsight through external agentic tools such as ChatGPT, Gemini or Claude without logging into Gainsight. Listen
Chuck Ganapathi says Gainsight launched its MCP interface about a month before Pulse, and all its products now have one. He says this lets customers work in their preferred agentic tool and use Gainsight without ever having to log into it, and that the Gainsight CLI lets admins configure the product through coding agents.
“you can use Gainsight without ever having to log into Gainsight”
Listen to the episode Episode Product Link to this Report a problem
The traditional application UI will eventually fade, with LLMs becoming the main workspace regardless of the back-end application. Listen
Diane Wu says that in the old world CSMs used multiple tabs and tools to get the context they need, and she expects this to go away. She describes the LLM as the new workspace, with the interface being natural language rather than visual, at least today. She adds that this might change very quickly in the future.
“I'm a believer of the traditional application UI is going to eventually fade and go away and LLMS will become the new workspace”
Listen to the episode Episode Product Link to this Report a problem
Brady Bluhm predicts that in about two years people will not need to log into product UIs, because LLMs are improving faster than other software. Listen
Brady Bluhm says he had a product manager's existential moment after playing with Staircase's MCP and asking why anyone would log into his product in a year and a half or two years. He expects that change because LLMs themselves are improving faster than other software. He still builds for the UI today because not everyone works in LLMs all the time.
“in two years from now, I think that's going to change because the LLMS themselves evolved so much faster than any other product will too”
Listen to the episode Episode Product Link to this Report a problem
Headless access alone is not enough; purpose-built interfaces still matter alongside API and MCP access.
said Mark Vovsi ([Un]Churned), Adam Liska (Topline), Steve Cox (Topline)
3 sources
Mark Vovsi expects CS insights to live in a combination of a cockpit-style CSP and conversational AI tools. Listen
He said conversational access through Claude, MCP or similar suits quick questions, but he still sees a need for a platform where people can see information in one view. He said a summary from a chat tool can run to three pages, while a CSP organises the information and shows where to focus at the start of the day. He said he does not think the headless model has arrived yet.
“I think the future is a combination.”
Listen to the episode Episode Product Link to this Report a problem
Saying a product is headless is too easy an answer, and that the interface still matters and should be rebuilt for each role. Listen
Adam agrees most software will support headless access through APIs and MCP. He says people don't just connect a chat model to all their systems and push it to act; they need to be served the context and data required to figure out the next best step. He says UX and UI remain important and that the interface should differ for a sales manager, a rep and a CRO. He describes this as a more flexible, adaptable interface that can be rebuilt around each person's goal.
“But really, I think just saying Headless will solve everything, I think it's quite a, you know, it's an easy way to get out.”
Listen to the episode Episode Product Link to this Report a problem
Steve Cox describes his product approach as keeping a shared logic and context layer while building different interfaces for SMB, mid-market and enterprise customers, including headless access. Listen
He says the underlying logic and context layers remain the same, and that the company can build a skin suited to each segment. He says headless access lets customers consume the intelligence however they want, and that the company's MCP server is live and already gaining traction.
“I think underlying the logic layer and the context layer remains the same and then I think you're on top of that you have the opportunity to build a skin right that's suitable for you know SMB customers mid-market.”
Listen to the episode Episode Product Link to this Report a problem
Those predicting UI decline focus on fast-improving LLMs for quick queries, while defenders focus on users who need organised, role-specific views to decide daily priorities.
Embedding engineers with customers to build customer-specific solutions, then productizing the ones that recur, is an effective way to build product.
said Grant Clarke ([Un]Churned), Rick Smolen (Topline), Cassie Young (Topline), Diego Ballona ([Un]Churned)
7 sources
Atlas turns recurring human-handled escalations into agent capabilities through forward deployed engineers who ship them in roughly two-week sprints. Listen
Grant Clarke says Atlas records what reps do outside the agent's handoffs and classifies those actions into buckets. Forward deployed engineers, product managers and business analysts sit 'in the boat' with renewal managers to monitor this. When a category of escalation recurs multiple times, it becomes a product requirement. The FDE team develops it in maybe two weeks, tests it for a few weeks, and puts it back into Atlas.
“The FDE team can sprint, develop that in maybe two weeks, run a few weeks of testing, and then it's right back into Atlas to handle the next customer issue that comes up.”
Listen to the episode Episode Product Link to this Report a problem
Rick suggests building customer-specific applications alongside the core product so a company can say yes to edge-case requirements, with forward-deployed engineering teams as a way to do it. Listen
Rick says a core offering may handle around 90% of what customers need, and that the remaining edge cases can be handled by building applications that complement the core product. He says this is more possible now, but that it adds complexity because forward-deployed engineering teams must work with core engineering. He says each organization should decide which things it will not build into the core product but will still say yes to.
“what are the things that we're not going to build into our core offering? But we should be able to say yes to”
Listen to the episode Episode Product Link to this Report a problem
Implementation is moving out of customer success and into the product org in some portfolio companies. Listen
Cassie says she is seeing a notable organizational change in portfolio companies: implementation, previously in the chief customer officer or post-sales lane, is moving into product. Companies view getting customers up and running as a product opportunity, and the best organizations productize what they learn from forward-deployed work immediately.
“implementation in many places is being moved out of the chief customer officer lane or the post-sales lane and into product”
Listen to the episode Episode Product Link to this Report a problem
Forward-deployed engineers only form a true model when implementation work feeds a feedback loop into product. Listen
A host says many AI companies have forward-deployed engineers but no plumbing connecting them to product, so the work is just implementation. He says the true FDE model is one where that work feeds back into what gets built, which is what made the Palantir model special. Cassie agrees, saying Primary has discussed the Palantir model internally and that Palantir built product off it rather than just selling services.
“The whole FTE concept was it was going to help Palantir figure out what to build and that feedback loop is what was so special about the whole model”
Listen to the episode Episode Product Link to this Report a problem
Diego describes a split in which FDE builds early prototypes for specific customers and a core product team later productizes them. Listen
He said FDE works on early prototypes with specific customers. Once a product becomes a big part of the platform's infrastructure and needs more investment, a core product team takes ownership and productizes it for all customers.
“But at some point, it makes sense for a core product team to own the product because it becomes a big part of like our infrastructure of our platform.”
Listen to the episode Episode Product Link to this Report a problem
A Slack channel support feature began as a rapid prototype for one customer and was productized within about three months. Listen
A customer had a large share of its support volume on Slack, which Fin did not support at the time. Engineers sat with the customer's head of support, and an engineer estimated a version could be built in two to three weeks. Intercom built it for that customer despite it not being on the roadmap, and because demand was validated, it was productized into a general availability product in about three months.
“we actually decided to invest in that because we validated demand.”
Listen to the episode Episode Product Link to this Report a problem
Engineers sitting with customers feel the pain first hand, which Diego says speeds up iteration and ownership. Listen
Diego said this is different from aggregated research or metrics, which he called very valuable but slower to act on. He said the FDE motion has led Intercom to build a better product for all customers and better internal tooling for its go-to-market team.
“when you get engineers sitting with customers directly, they feel the pain first hand.”
Listen to the episode Episode Product Link to this Report a problem
Saying yes to one-off customer requests and custom builds creates unmaintainable complexity and wastes engineering.
said Rebecca Nerad ([Un]Churned), Snehal Nimje (Topline), Steve Cox (Topline), Frederic Kerrest (The Science of Scaling)
4 sources
Nerad warns that AI tempts CSMs to build a custom dashboard for every customer, which risks recreating unmaintainable software customizations. Listen
Nerad described a CS director at another company who builds customized dashboards from product data for each customer, and said customers love it. Her concern is how that scales. She said ideas CSMs develop with customers must be fed back into the product, or the industry ends up where software was 25 years ago, with customizations it can't maintain.
“Else we're going to end up in the place where software was when I got into the industry 25 years ago with all the customizations that we aren't able to maintain too”
Listen to the episode Episode Product Link to this Report a problem
Saying yes to every customer request made Outdoo's product chaotic and its marketing pages messy. Listen
Snehal said the team would try to please any customer and ship requested features quickly, and each new request led to more requests. The result was many features and settings that made the product complicated from the product side and from the marketing side, which the team saw as part of the problem before narrowing focus.
“So it became more chaotic from the product side.”
Listen to the episode Episode Product Link to this Report a problem
Just because a company can build a custom solution does not mean it should, and that most mid-market companies do not want to own architecture and integration. Listen
He says not everybody is a good architect, and that many mid-market buyers do not want to stitch point solutions together. He argues the answer is to keep the product simple rather than rely on forward-deployed engineers and custom builds.
“just because you can build it doesn't mean you should”
Listen to the episode Episode Product Link to this Report a problem
Kerrest warns that when salespeople sit between founders and customers, quota pressure leads them to push one-off feature requests that waste scarce engineering resources. Listen
Kerrest says reps trying to hit a number will insist a feature is needed to land a big customer and that everyone wants it, when it turns out to be a corner case only that customer needs, and possibly not even required to close the deal. Founders who aren't talking directly to customers lose the information needed to judge this.
“if we build this feature We're gonna get this big customer and everyone else wants it turns out no one else wants it”
Listen to the episode Episode Product Link to this Report a problem
Custom work pays off for enterprise vendors with a disciplined path back into the core product, but becomes bloat for mid-market sellers or teams that never productize it.
From one operator's experience
What one named guest described doing or seeing. Each is a single account, not a point several operators agree on.
“we can randomize both the orchestrator and the harness for the agent so we can collect all of those interaction effects that make it challenging.”
“And of course, the name your own price for an airline in Europe is a really bad idea.”
“you can shoot more end to end from the very beginning at scale, and I think doing so puts you on this path of rapid self-improvement.”
“We know that for an implementation for Vantagepoint for X number of employees, it should take around eight months.”
“in the investment bank when you trade on the interbank market, the minimum ticket size is like tens of millions”
What to do
- Put your product manager and lead engineer through about 10 back-to-back conversations with one customer segment so they build pattern recognition; Jeanne Grosser (Grit) used this at Vercel to settle whether slow growth was a product or go-to-market problem.
2 sources
To settle whether slow growth is a product problem or a go-to-market problem, Vercel ran its PM and lead engineer through 10 back-to-back customer conversations, and concluded it lacked full enterprise product-market fit. Listen
Grosser said no one has invented a test for product-market fit, so the question of product versus go-to-market keeps coming up. At Vercel she picked 10 large existing enterprise customers that used Vercel but not yet in front of their main site, and had the product manager and lead engineer hear all 10 in a row to build pattern recognition. Afterwards everyone agreed there were product gaps to close before the product would be much more easily sellable. She noted that some enterprises still buy before full fit, because a visionary buyer will always work through the pain.
“So we're like, great, let's go get 10 of those. Let's get the product manager, lead engineer, and let's run them through conversations with all 10 in a row, so they can get pattern recognition.”
Listen to the episode Episode Product Link to this Report a problem
Engineers should talk directly to practitioners who use the product rather than hearing customer feedback through several layers of translation Listen
Azam said engineering organizations easily slip into a pattern where engineers do not talk to customers because product is the first layer. He said the best engineers want direct contact, and a direct conversation with a practitioner from time to time beats feedback relayed through three abstracted organizations. A host added that such engineers then change their language with sellers, helping them stand in the user's moment of pain.
“there's nothing like getting an engineer to speak to a practitioner who's using their product directly”
Listen to the episode Episode Product Link to this Report a problem
- Before building, ask prospects to sign a design-partner letter of intent at a 90% discount, as Mark Roberge Roberge (The Science of Scaling) does, and probe past usage by asking 'tell me the last time that happened', as Josh Schachter ([Un]Churned) does.
2 sources
Roberge tests early interest by asking prospects to sign a design-partner letter of intent at a 90% discount, to separate false positives from true positives. Listen
Roberge's example: tell the prospect the product launches in two months at $50,000 a year, and that you want five design partners to sign a letter of intent at a 90% discount, $5,000. Asking them to commit money, drawing on Steve Blank's idea that the hardest thing is separating someone from their wallet, reveals whether a stated 'yes, I'd use this' is real. He applies this before the product exists.
“But by pushing them to separate them from their wallet gives us the real feedback. It's a differentiation between a false positive and a true positive.”
Listen to the episode Episode Product Link to this Report a problem
In user research, asking for the last time something happened gets more than asking how often it happens. Listen
Josh Schachter describes design-thinking user research from his time at BCG. Asking 'how often do you do X?' got thin answers like 'every other month'. Following up with 'tell me the last time that happened, give me that situation' put people in a concrete scene. He links this to London's hypothetical scenes, saying both let the person picture a situation.
“okay, great, well, tell me the last time that that happened. Like, give me that situation.”
Listen to the episode Episode Product Link to this Report a problem
- Log recurring escalations and turn them into product requirements shipped in roughly two-week sprints, as Grant Clarke's team does at Gainsight, then hand mature prototypes to a core product team, as Diego Ballona describes at Intercom (both [Un]Churned).
3 sources
Atlas turns recurring human-handled escalations into agent capabilities through forward deployed engineers who ship them in roughly two-week sprints. Listen
Grant Clarke says Atlas records what reps do outside the agent's handoffs and classifies those actions into buckets. Forward deployed engineers, product managers and business analysts sit 'in the boat' with renewal managers to monitor this. When a category of escalation recurs multiple times, it becomes a product requirement. The FDE team develops it in maybe two weeks, tests it for a few weeks, and puts it back into Atlas.
“The FDE team can sprint, develop that in maybe two weeks, run a few weeks of testing, and then it's right back into Atlas to handle the next customer issue that comes up.”
Listen to the episode Episode Product Link to this Report a problem
Diego describes a split in which FDE builds early prototypes for specific customers and a core product team later productizes them. Listen
He said FDE works on early prototypes with specific customers. Once a product becomes a big part of the platform's infrastructure and needs more investment, a core product team takes ownership and productizes it for all customers.
“But at some point, it makes sense for a core product team to own the product because it becomes a big part of like our infrastructure of our platform.”
Listen to the episode Episode Product Link to this Report a problem
A Slack channel support feature began as a rapid prototype for one customer and was productized within about three months. Listen
A customer had a large share of its support volume on Slack, which Fin did not support at the time. Engineers sat with the customer's head of support, and an engineer estimated a version could be built in two to three weeks. Intercom built it for that customer despite it not being on the roadmap, and because demand was validated, it was productized into a general availability product in about three months.
“we actually decided to invest in that because we validated demand.”
Listen to the episode Episode Product Link to this Report a problem
- Time-box each product bet to one, two or four weeks with a stated confidence threshold, such as 80%, before it reaches the roadmap, following Jo Massie at Slido ([Un]Churned) and Bryan Murphy at Smartling (Topline).
2 sources
Slido ties its experiments to a time budget of one, two or four weeks. Listen
Jo Massie said the team asks how much time and budget a project deserves, such as one, two or four weeks. She said anything taking more than four weeks to implement is quite expensive, so the team needs to see results from it. She said that if an idea does not work, the team should not invest too much in it, and that small pilots are the way to start.
“How much time are we willing to give this one week, 2 weeks, 4 weeks?”
Listen to the episode Episode Product Link to this Report a problem
Smartling time-boxes R&D bets and requires each to reach a stated confidence level within a set number of weeks, or it is dropped. Listen
Bryan said each idea is framed around a customer problem, given a set number of weeks to prove out, and measured against a confidence level. He said they give a little latitude but then move on to the next idea on the list, so they keep moving forward. He said that once an idea reaches a high confidence level, giving 80% as an example, it moves into the product and engineering roadmap.
“and you're going to be able to measure it with a confidence level”
Listen to the episode Episode Product Link to this Report a problem
- Let RevOps or go-to-market teams stand up a stopgap tool and then hand proven tools to product, as Lauren Hughes did at Justworks and Usha Iyer did with integrations now bought by over 30% of Hivebright's customers (both on Kyle Norton's podcast).
2 sources
Justworks' build-versus-buy stance is that RevOps stands up a short-term tool, giving product air cover to build it properly into the product later. Listen
The census tool went from a bought wrapper tool, to an internal build, to a product-team build into the Justworks product, going live after about a year. Internal productivity tools generally stay with RevOps and go-to-market engineering, but some belong in the product, especially for self-service. Lauren Hughes said there was push and pull with product in reaching this approach.
“We've kind of taken the stance that revenue operations will stand up something in the short term to increase immediate productivity on the floor. And we'll buy air cover for our product team to develop that the right way over time”
Listen to the episode Episode Product Link to this Report a problem
A GTM-built set of pre-built integrations was sold before product took it over, and over 30% of customers now buy them. Listen
Usha says HiveBright has robust APIs but had no pre-built integrations, so she proposed getting a middleware platform and a contractor to build a few integrations, noting that a connector such as Salesforce or HubSpot does not take much. They built a couple, pitched them and saw traction, and over 30% of customers now buy them. The product team has since taken them over.
“now over 30 % of our customers buy pre -built integrations from us.”
Listen to the episode Episode Product Link to this Report a problem
4 more
- Track whether customers use the features tied to their intended use case, not just whether they log in, as Christine Lavery ([Un]Churned) recommends, and get core data set up before pushing AI features, as Rob Edmondson learned at Ironclad ([Un]Churned).
2 sources
Christine distinguishes basic product usage tracking from tracking whether customers use the features tied to the use case they should be pursuing. Listen
Basic product analytics asks whether customers are using the product at all. More sophisticated tracking asks what use case a customer should be using the product for and whether they use the features associated with it. If they do not, Christine says the team can advise them on how to use the product to reach their outcomes. She describes product analytics as her first 2026 priority, with cross-functional work underway.
“The more complex or sophisticated ones are around what's the use case that a customer should be using our product for, and are they using the features associated with that particular use case?”
Listen to the episode Episode Product Link to this Report a problem
At Ironclad, downmarket customers who tried AI features too soon did not have good outcomes, and getting fundamental data structures right in onboarding came first. Listen
Rob said that for downmarket customers, trying to adopt AI features early did not correlate well with a good outcome. He said getting some fundamental data structures right as part of onboarding was important before applying the AI features. Ironclad now uses these findings to decide where to intervene.
“for for AI features within our product, if they tried to adopt them too soon, it actually didn't correlate well to a good outcome.”
Listen to the episode Episode Product Link to this Report a problem
- Reward engineers for deleting code as much as for shipping features, as Arvind Jain does at Glean (Grit), so the stack does not turn into legacy software.
1 source
Glean rewards building new features at the same level as removing code from the codebase. Listen
He says he tells the R&D team to reward building new things as much as throwing code out. His reasoning is that without deleting code, the stack slowly turns into a legacy software stack. He describes this as a practice he asks of his own team at Glean.
“reward, building new stuff as much at the same level as throwing some stuff out of your code base. Because if you're not throwing things out, it means you're sort of slowly and slowly converting into a legacy software stack.”
Listen to the episode Episode Product Link to this Report a problem
- Aggregate feature requests across the whole customer base into a ranked list before they reach product, as Notion does with agents (Christina Parra, [Un]Churned) and as Abbas Haider Ali ([Un]Churned) describes for GitHub's CSMs.
2 sources
Notion runs a multi-agent feature-request pipeline that captures requests from Gong and Slack, checks Salesforce, and maintains a ranked top-10 list. Listen
A former solutions engineer designed the system, and CSMs use it constantly. An intake agent listens to Gong calls and monitors a Slack channel where CSMs post requests. Another agent restates the request in natural language, another checks Salesforce for whether the requester is a customer, and another logs it in a database. That gives a top-10 feature request list across customers, and requests are referenced in customers' AI transformation plans. The next step Christina Parra described as planned is an automatic alert to the customer when a request ships, to build trust.
“There's another one that checks Salesforce to see, is this a customer, is this not a customer?”
Listen to the episode Episode Product Link to this Report a problem
Abbas describes CSMs validating customer feature requests and combining them across the portfolio before sending them to product. Listen
He said a CSM should grab feedback from a customer, validate that it is important, combine it across the entire portfolio, and have it delivered to the product team. This lets the product team prioritize what unlocks the business. He presented this as the mechanism for handling incomplete features in the health model.
“let me grab the feedback from my customer, validate that it actually is important, combine it across the entire portfolio and have that delivered to our product team so you can prioritize what unlocks the business.”
Listen to the episode Episode Product Link to this Report a problem
- For conversational AI, target about 500 milliseconds of latency, per Alex Varel (Revenue Builders), and cover heavier reasoning with holding phrases, as Amanda Kahlow's 1mind does (Topline).
2 sources
For conversational AI, Alex puts the latency target at about 500 milliseconds or less. Listen
He describes a pharmacy's conversational bot with a two second response target, which he calls way too slow for conversation, and says conversational use needs roughly 500 milliseconds or less. He says Cerebras powers instant AI for conversational, agentic coding and deep search use cases. He describes asking a prospect what changes if responses arrive in 200 milliseconds against a 500 millisecond target.
“You need to be like 500 milliseconds or less, right?”
Listen to the episode Episode Product Link to this Report a problem
Keeping latency low is hard when the AI carries a lot of context, so her team uses filler and holding phrases. Listen
Amanda Kahlow says the live demo product sits inside a customer's product and carries a large amount of context, which makes latency hard to keep down. Her company uses filler words and holding phrases to make the response feel instant while the system works through a hard reasoning problem. She says they measure accuracy, latency, speed and cost in multi-agent orchestration.
“Now there's a lot of things you can do to fake it. Like, hey, let me pull that up for you.”
Listen to the episode Episode Product Link to this Report a problem
All 23 positions best supported first
- Users will increasingly stop logging into application interfaces and instead work through LLMs and agentic tools connected to back-end software.
4 independent voices · 2 shows1 new this month
said Ann Davis (Revenue Builders), Chuck Ganapathi ([Un]Churned), Diane Wu ([Un]Churned), Brady Bluhm ([Un]Churned)
4 sources
- Embedding engineers with customers to build customer-specific solutions, then productizing the ones that recur, is an effective way to build product.
4 independent voices · 2 shows1 new this month
said Grant Clarke ([Un]Churned), Rick Smolen (Topline), Cassie Young (Topline), Diego Ballona ([Un]Churned)
7 sources
- AI making features cheaper to build does not mean shipping more of them, because more features lead to bloat and incoherent products.
4 independent voices · 3 shows2 new this month
said Dan Lee (The Science of Scaling), Keith Peiris (Topline), Steve Cox (Topline), Karri Saarinen (Grit)
4 sources
- Structured batches of direct customer conversations are an effective way to find or test product-market fit.
5 independent voices · 4 shows2 new this month
said Jeanne DeWitt Grosser (Grit), Alex Mashrabov (The Twenty Minute VC), AJ Bruno (Topline), Baiju Bhatt (Grit), Frederic Kerrest (The Science of Scaling)
6 sources
- Saying yes to one-off customer requests and custom builds creates unmaintainable complexity and wastes engineering.
4 independent voices · 3 shows1 new this month
said Rebecca Nerad ([Un]Churned), Snehal Nimje (Topline), Steve Cox (Topline), Frederic Kerrest (The Science of Scaling)
4 sources
- Product builders should personally watch and talk with customers using the product rather than rely on feedback relayed through other teams.
3 independent voices · 2 shows1 new this month
said Dan Lee (The Science of Scaling), Lou Shipley (Revenue Builders), Sahir Azam (Revenue Builders)
4 sources
- Headless access alone is not enough; purpose-built interfaces still matter alongside API and MCP access.
3 independent voices · 2 shows
said Mark Vovsi ([Un]Churned), Adam Liska (Topline), Steve Cox (Topline)
3 sources
- Customer feedback should be systematically captured and aggregated across the customer base before it reaches product.
3 independent voices · 2 shows1 new this month
said Christina Parra ([Un]Churned), Christopher O'Donnell (The Science of Scaling), Abbas Haider Ali ([Un]Churned)
4 sources
- Teams should routinely throw away and rebuild code rather than preserve what they built before.
3 independent voices · 2 shows
said Parag Agarwal (Grit), Arvind Jain (Grit), Wade Foster (Topline)
4 sources
- Product bets should be time-boxed to a fixed number of weeks and dropped if they do not prove out.
2 independent voices · 2 shows
said Bryan Murphy (Topline), Jo Massie ([Un]Churned)
2 sources
- Buying software usually beats building internal AI tools, because maintenance, permissions and workflow complexity overwhelm in-house builds.
3 independent voices · 3 shows
said Christopher O'Donnell (The Science of Scaling), Liz Christo (Topline), Jeremey Donovan (The Revenue Leadership Podcast)
3 sources
- Go-to-market people should feed what they hear from customers straight to product and engineering, because tight loops ship what the market needs faster.
3 independent voices · 3 shows
said Jason Forget (Revenue Builders), Asad Zaman (Topline), Usha Iyer (The Revenue Leadership Podcast)
6 sources
- Pushing for scale or attention before the product actually works burns resources and must be reversed.
2 independent voices · 2 shows1 new this month
said Alex Mashrabov (The Twenty Minute VC), Aman Narang (Grit)
3 sources
- AI products should be evaluated and trained on real task outcomes rather than stated preferences or abstract technical metrics.
2 independent voices · 2 shows
said Anastasios Angelopoulos (Grit), AJ Meyer (Topline)
3 sources
- AI lets the person closest to a problem build the solution directly, removing specialist handoffs.
2 independent voices · 2 shows
said Christopher O'Donnell (The Science of Scaling), Ghazi Masood ([Un]Churned)
3 sources
- Build versus buy is a false choice, because customers can build their own tools on a vendor's platform and governance.
2 independent voices · 2 shows1 new this month
said Keith Peiris (Topline), Chuck Ganapathi ([Un]Churned)
2 sources
- Winning platforms consolidate many separate point tools into one unified product experience.
3 independent voices · 3 shows1 new this month
said AJ Bruno (Topline), Garrett Marker ([Un]Churned), Brian McCarthy (Revenue Builders)
4 sources
- A single demanding customer's request can open a larger use case that serves many customers.
2 independent voices · 2 shows
said Chris Degnan (Revenue Builders), Ed Calnan (The Science of Scaling)
2 sources
- Product and engineering are now shipping faster than marketing and go-to-market can keep up.
2 independent voices · 2 shows
said Kyle Lacy (Topline), Kevin Mandia (Grit)
2 sources
- Product-led growth forces a more complete, polished product and in-app experience than a sales-led motion.
2 independent voices · 2 shows
said Jaleh Rezaei (Topline), Samantha Murray ([Un]Churned)
3 sources
- Good product design favors familiar, stable interfaces over novelty and frequent UI changes.
2 independent voices · 2 shows
said Christopher O'Donnell (The Science of Scaling), Karri Saarinen (Grit)
2 sources
- Go-to-market teams should build stopgap tools to prove demand before the product team builds them properly.
2 independent voices · 1 show
said Lauren Hughes (The Revenue Leadership Podcast), Usha Iyer (The Revenue Leadership Podcast)
2 sources
- AI should be delivered inside the tools and workflows people already use rather than through new standalone apps.
2 independent voices · 1 show
said Justin Shriber (Topline), Steve Cox (Topline)
2 sources
Actions written 10 Oct 2026 from the most useful of 198 recent insights and checked against them.
What was said 40 insights matching
Dan spent 60 to 70% of each week observing customers using the product while Nooks focused on sales Listen
Dan Lee said that when Nooks went all in on sales, he spent 60 to 70 percent of his week observing customers using the product, which he described as the majority of his time. The team did this by spending time on the sales floor with the sales teams using Nooks.
“Um definitely the majority like 60 70%”
Listen to the episode Episode Product Link to this Report a problem
Interviewing eight creative directors surfaced one consistent gap, camera control, which became Higgsfield's breakthrough product. Listen
After the pivot, Higgsfield asked eight creative directors what was missing from AI video, and every one of them said camera control, which they called essential to storytelling. The product launched on March 31 and Mashrabov describes product-market fit as immediate. He says VFX and camera control took Higgsfield from roughly $1M to $20M ARR in about the first three months.
“We spoke to eight creative directors about their experience with AI and what's simply missing. Everyone told us that camera control does not exist in AI.”
Listen to the episode Episode Product Link to this Report a problem
Higgsfield burned more than $10M of a $16M seed chasing hype before finding product-market fit by focusing on product and PLG. Listen
Mashrabov says Higgsfield spent more than a year searching for a product that worked, and he takes responsibility for optimizing for hype, narrative and attention instead of building a good product. With slightly less than $5M left and feeling they had 'one attempt left', the team committed to product and PLG on the belief that the best product would win. That led to the launch that took off.
“I was so much optimizing for what's hype today, what's the right narrative, how we can hijack the attention, all these things, really. Everything instead of building a good product.”
Listen to the episode Episode Product Link to this Report a problem
At Day AI, a customer-facing person and a product person can spot an opportunity, verify its impact and ship it in about 45 minutes, without an analyst or designer. Listen
Christopher says there is no need for an analyst to quantify the problem or a designer to mock up options. Someone on the phones and someone in product sit together over coffee, find something, verify its impact and ship it. In his office, four or five people may talk for three hours around couches over data and customer feedback, and by the end the software is written.
“You need somebody on the phone and somebody in product to sit together over a coffee and get a lead on something you could do, verify that it's going to have this impact and ship it 45 minutes later.”
Listen to the episode Episode Product Link to this Report a problem
Early-stage technical founders should route all meeting recordings and Slack into one customer memory and automate from it, rather than relying on manually filed tickets. Listen
Asked for one tactic for young engineering founders building in a vacuum, Christopher (acknowledging he is promoting Day AI) suggests recording meetings and connecting Slack into a customer memory layer. From there feedback can flow automatically to GitHub, or be worked through Claude Code. He says the expectation should be past tickets: automated action, rolled-up strategic insights, and answers to questions like who a feature would affect or what the biggest gaps are for a new persona.
“I think we're definitely past the kind of ticket concept, you know, level and you should be able to have some sort of automated action off of that”
Listen to the episode Episode Product Link to this Report a problem
Bhatt credits Robinhood's breakthrough against entrenched brokers to insight into how people would use technology plus systematic customer conversations feeding product development. Listen
He calls mass-market consumer product-market fit extraordinarily difficult, especially when many talented, well-resourced incumbents already serve the market. Robinhood broke through by pairing its view of how people would use mobile with systematic processes for understanding customer needs and flowing them into what it built.
“through pretty systematic ways of talking to customers and understanding what their needs are, and, you know, flowing those into the product development.”
Listen to the episode Episode Product Link to this Report a problem
Designing the rocket, satellite and data center as one integrated system led Cowboy Space to make the rocket's upper stage itself the data center. Listen
Bhatt gives two realisations. First, two GPU racks are more useful next to each other than apart, so one big satellite beats two small ones. Second, the thorniest part of a space data center is dissipating heat, which normally means carting radiator mass to orbit. Instead the company reuses the rocket's own metal: in orbit the nose pops off, solar panels deploy, and the fairing's cylinder folds out as a heat-dissipating radiator, eliminating a separate satellite and, the company believes, giving one of the lowest-cost ways to do compute from orbit.
“the upper stage of the rocket is itself the data center. There's no satellite, the rocket becomes the data center satellite once in orbit.”
Listen to the episode Episode Product Link to this Report a problem
Saying yes to every customer request made Outdoo's product chaotic and its marketing pages messy. Listen
Snehal said the team would try to please any customer and ship requested features quickly, and each new request led to more requests. The result was many features and settings that made the product complicated from the product side and from the marketing side, which the team saw as part of the problem before narrowing focus.
“So it became more chaotic from the product side.”
Listen to the episode Episode Product Link to this Report a problem
Airwallex got interbank FX access by convincing Macquarie to change its API to allow trades with a $50,000 minimum ticket. Listen
Jack cold-called Macquarie early one morning and reached a staffer covering an overnight shift, then pitched the vision with about $3 million raised. The bank agreed to a fixed connectivity arrangement that let Airwallex reach the interbank market. Jack said the minimum ticket size there was normally tens of millions, and Airwallex became Macquarie's largest customer.
“in the investment bank when you trade on the interbank market, the minimum ticket size is like tens of millions”
Listen to the episode Episode Product Link to this Report a problem
Jason agreed that early salespeople are partly product managers, calling it a very early-stage skill that is gold for the business. Listen
One host said early-stage sellers are part product manager because the product will not yet do everything it claims, so they must sell around gaps while giving honest customer feedback to development. Jason agreed and said this becomes less necessary once the company has product marketing and product management teams. He called the ability gold for the business.
“in the early days, the salespeople are part salespeople, part product manager.”
Listen to the episode Episode Product Link to this Report a problem
Building your own hardware on a $100K check is very hard, so Toast used commodity Android tablets. Listen
Toast bought off-the-shelf Android tablets and related accessories rather than building its own hardware, using Amazon and Alibaba among other sources. Aman said this was a cost-driven choice given the size of the early funding. He noted that these tablets had design issues, such as a change in port configuration, that caused problems.
“It's very hard on 100K checks to build hardware.”
Listen to the episode Episode Product Link to this Report a problem
Pushing to scale before the product was ready exposed gaps in hardware, offline functionality and support. Listen
After early customers arrived, investor Steve Papa pushed the team to put the pedal down, but Aman said the software did not work offline, the hardware was not ready for deployment, and support was not in place. He recalled that 100% of the first hardware iteration came back within roughly 80 days. Steve Papa and co-founder Steve Fredette told the team to slow down and fix these foundations.
“We thought we were ready to scale, but because of the complexity of the hardware, the software, the support, we just really were not ready.”
Listen to the episode Episode Product Link to this Report a problem
Cursor's early growth came from engineers using the product themselves in a self-serve motion, without sales involvement. Listen
Brian said the early spread came from getting engineers using the tool, with about 3 million engineers using it, and that Cursor was the best at anticipating code completion. He said you didn't need sales for that, because it was self-serve.
“It was just get engineers using it, it self-serve.”
Listen to the episode Episode Product Link to this Report a problem
Engineering is ahead of marketing for the first time in his career at Armadin. Listen
Mandia says at Armadin engineering is ahead of marketing, which he contrasts with the usual pattern where marketing gets well ahead of the product. He says they plan to hold a demo every Friday and update the sales team on where the product is. He expects a much more rapid cycle between engineering and what is taken to market.
“For the first time in my career, engineering is ahead of marketing.”
Listen to the episode Episode Product Link to this Report a problem
Armadin plans to build nation-state-grade offensive capability to train defenses. Listen
Mandia says Armadin has to build a nation-state-grade offensive capability so it can train the defense. He says the goal is to show customers what attacks are possible before they happen. He describes the platform as a way to assess security and train defenses against the most effective attacks.
“So Armadin has to build a nation -state grade capability on offense to train the defense.”
Listen to the episode Episode Product Link to this Report a problem
1mind's onboarding for a new superhuman has dropped from about four months to about four weeks, based on its recent customers. Listen
Kahlow said onboarding used to take four months, and across roughly the last 20 customers it has come down to about four weeks. She credited automatic knowledge ingestion: 1mind scrapes the customer's website, links to sales enablement tools such as Seismic or Highspot, takes in pitch decks and sets goals, and the hardest part is integrating other systems.
“our onboarding used to be four months. And our last call it 20 customers, we got it down to four weeks.”
Listen to the episode Episode Product Link to this Report a problem
When founders declined an enterprise request for a private cloud version, sales had to change the ideal customer profile. Listen
Chris Degnan said large enterprises kept asking Snowflake when it would offer a private cloud, and the founders said never. He said he had to change the strategy on who the ideal customer profile would be. He said the founders wanted to solve technical problems for customers, and that customer-led focus is still part of the company's culture.
“And our founders would say, never. So I would have to change my strategy on who our ideal customer profile would be.”
Listen to the episode Episode Product Link to this Report a problem
A demanding early customer's requirements forced product work that later became a faster, cheaper feature and helped win Nielsen. Listen
Localytics ran a 500-plus terabyte Vertica cluster on Amazon and needed data clustered in a way Snowflake did not support. Chris Degnan said the rebuild took the engineering team about seven months. The work let Snowflake turn on a recluster feature that made it faster and cheaper than open-source tools, and Nielsen then signed, which he called material.
“They had a 500 plus terabyte Vertica cluster on Amazon.”
Listen to the episode Episode Product Link to this Report a problem
Identity and IT-infrastructure products take longer to become sellable because of the high security bar; Okta needed about two and a half years. Listen
Okta started in 2009 during the recession with a $1M seed round of convertible debt in the summer of 2009. Kerrest says it took roughly two and a half years to reach a product that could work at scale with hundreds or thousands of users, and that this is common for IT ops and DevOps middle-layer products.
“But it took us like two and a half years to get a product that was really out there that could work, that could work at scale with hundreds or thousands of users.”
Listen to the episode Episode Product Link to this Report a problem
Okta's 2009 discovery approach should be modified today: founders should have at least the core product running during early conversations. Listen
Kerrest says Okta took about two and a half years to build a product that worked at scale, and relied on drawings and documents in early discovery. Because products can now be built faster and more cheaply, he says founders should spin up the core early so prospects can see how it would be valuable from the start.
“So I would actually argue that like the lessons that we learned there should actually be modified for today's world. So today it's like you should have it up and running.”
Listen to the episode Episode Product Link to this Report a problem
Roberge tests early interest by asking prospects to sign a design-partner letter of intent at a 90% discount, to separate false positives from true positives. Listen
Roberge's example: tell the prospect the product launches in two months at $50,000 a year, and that you want five design partners to sign a letter of intent at a 90% discount, $5,000. Asking them to commit money, drawing on Steve Blank's idea that the hardest thing is separating someone from their wallet, reveals whether a stated 'yes, I'd use this' is real. He applies this before the product exists.
“But by pushing them to separate them from their wallet gives us the real feedback. It's a differentiation between a false positive and a true positive.”
Listen to the episode Episode Product Link to this Report a problem
In pre-product discovery at Okta, Kerrest set himself a quota of 18 net-new IT professional conversations a month and tracked each one on a color-coded sheet. Listen
Starting around August 2009, for four months, Kerrest talked to IT professionals about their problems and whether they would use or buy a solution, and showed them drawings, documents and pictures. He tracked each name and contact date in green, yellow or red, and says he missed his number in some months. He cites Peter Thiel's Zero to One and Steve Blank's Four Steps to the Epiphany as the basis for the approach.
“I had a monthly plan where I had to go talk to 18 net new IT professionals and just talk to them and say, Hey, what kind of problems do you have? Do you have this problem? Would you use this? Would you buy this?”
Listen to the episode Episode Product Link to this Report a problem
A bundling strategy only works if the product demos well. Listen
Dmitri said the bundling approach worked for Perplexity because people who used the product really liked it, and a weak product would not get bundled. He tied the strategy's success to how the product demonstrates in practice.
“This was a strategy that worked because the product demos well.”
Listen to the episode Episode Product Link to this Report a problem
A customer's request for batch generation by administrators opened a bigger use case, and Seismic did not need to change the product much to serve it. Listen
Ed said the team had built a wizard that let individual users create their own sales collateral. A customer asked whether an administrator could generate materials for everything in batch and push them to sellers. Ed said the product did not need much change to do that.
“And we didn't have to change much for the product. That's the key.”
Listen to the episode Episode Product Link to this Report a problem
A manual quarterly collateral process that took six people about 10 weeks was reduced to one person over 10 days with Seismic, and became its first high-value use case. Listen
A TIAA-CREF contact said updating quarterly marketing collateral for mutual fund companies was his biggest pain point, and Ed said Seismic would prove it could solve it. Ed said the manual work took an average of six people 10 weeks at each quarter end, and with Seismic it took one person 10 days. The buyer agreed to buy if the proof worked.
“It takes you 10 weeks with an average of six people to do this work at the end of the quarter. If you use seismic, it'll take you 10 days with one person.”
Listen to the episode Episode Product Link to this Report a problem
Before taking a customer request to product and engineering, ask whether it will help one customer or many. Listen
Greg says the team trained reps to ask whether a requested feature would help only one customer or a broad set of customers. They also asked whether a large customer could become a website name or case study, and only escalated when they felt they had something with real impact.
“Is this just going to help this one customer or is this something that's going to help this customer?”
Listen to the episode Episode Product Link to this Report a problem
A rep relaying customer needs to engineering quickly led to a room connector that Zoom built in about three months and used to win against BlueJeans. Listen
Daniel, one of the first two reps Greg hired, went from his calls straight to the engineering office with what he was hearing, and pushed for the product to connect video endpoints with browsers and Skype. Greg says the engineering team built the first version, called the room connector, within about three months, and the company started winning against BlueJeans, which had been connecting endpoints.
“Within like three months we had like first version of this we called it the room connector and all of a sudden we started knocking out knocking out BlueJeans”
Listen to the episode Episode Product Link to this Report a problem
Prospects buy when a solution costs materially less than what they pay to solve the problem today. Listen
Mike said consumer intent is hard to predict, but a business with a problem that it is open about will buy when a solution solves it for materially less than the cost of solving it today. He contrasted this with consumers, whose behaviour he said is fickle.
“if I can solve it for materially less than it costs you to solve it today, you're open to buying that solution.”
Listen to the episode Episode Product Link to this Report a problem
Demand can be tested with mock-ups, a landing page and paid ads before spending months building the product. Listen
Mark argues that founders often assume an MVP test means spending three months building the product, and says that is rarely necessary. He suggests setting up a couple of paid ads and a landing page, sending people to it, and treating any sign-ups as a learning signal before committing to the build. He says these learning moments give significant confidence about whether the planned build will be sellable.
“Like rarely is that necessary. And what they're doing here is mock-ups.”
Listen to the episode Episode Product Link to this Report a problem
Market validation can be run as a structured tour of about 30 prospects, with a mock-up-driven MVP refined between visits. Listen
Mike said LinkedIn used a process taught by Frank Robinson in which a product manager, an engineer and a sales or marketing person travelled in waves of five or six prospects and changed mock-ups back at the hotel for the next day. The aim was to exit with 10 or 15 prospects contractually committing to buy at a stated price if the product was built as described. He said the team spoke to 30 prospective clients in total.
“You go off and you speak to 30 prospective clients.”
Listen to the episode Episode Product Link to this Report a problem