# Last Mile Stack

> Delivering the last mile between platform features and what the customer needs. Demos, data orchestration, AI enrichment, and answer-layer visibility — from inside enterprise pre-sales cycles.

## Posts

### Your AI Shopping Agent Can Only Answer What Your Catalog Already Knows
Source: https://www.lastmilestack.com/writing/your-ai-shopping-agent-can-only-answer-what-your-catalog-already-knows
Entities: Conversational commerce, Product catalog data enrichment, Feedonomics Data Enrichment, Feedonomics, Adobe AI Content Visibility Checker, Baymard Institute ecommerce benchmark

AI shopping agents answer reliably only when catalogs have structured, normalized evidence per constraint. Price is usually present, but care, age suitability, materials, and safety attributes are often missing, inconsistent, or buried in prose. Retailers should test conversational commerce on full catalogs with unannounced, multi-constraint queries, scoring recall and correctness separately and noting which attribute resolved each constraint.

Q: Why does an AI shopping agent return wrong products for detailed queries?
A: An AI shopping agent can return wrong products when the catalog lacks structured evidence for constraints such as care instructions, age suitability, materials, or safety. Without that evidence, the agent must either return nothing or guess from product-description text, and text guesses can produce unsafe or incorrect recommendations.

Q: How should I test a conversational commerce vendor on my product catalog?
A: Test the conversational commerce vendor on a real catalog export that includes long-tail products, not a cleaned sample. Use twenty unannounced queries with three or four stacked constraints, score recall separately from correctness, and require the vendor to identify which catalog attribute resolved each constraint.

Q: What product data does an AI shopping agent need?
A: An AI shopping agent needs structured and normalized attributes that provide evidence for shopper constraints. Common commerce fields such as title, price, GTIN, brand, image, and category are not enough when queries depend on material, care instructions, age range, weight limits, non-toxic finishes, or detachable-part details.

Q: Why should recall and correctness be scored separately for AI product recommendations?
A: Recall measures whether the system returns products, while correctness measures whether the returned products actually satisfy the query. A confident but incorrect recommendation is worse than no recommendation, especially when the query includes safety constraints such as toddler suitability.

Q: How does product feed enrichment improve conversational commerce?
A: Product feed enrichment fills missing attributes, normalizes inconsistent attribute names and values, and derives fields that suppliers or commerce channels did not populate. The resulting catalog can support queries that previously lacked enough structured evidence, while the enriched data can also support advertising and marketplace feeds.

### The One Constant in ChatGPT Shopping: Your Product Feed
Source: https://www.lastmilestack.com/writing/the-one-constant-in-chatgpt-shopping-your-product-feed
Entities: ChatGPT shopping, OpenAI Agentic Commerce Protocol, OpenAI Instant Checkout, Feedonomics, Shopify, Etsy

ChatGPT shopping depends on a structured product feed that is refreshed regularly, even when shoppers complete purchases on a merchant’s e-commerce site rather than inside ChatGPT. Merchants should provide secure CSV or JSON data with stable identifiers, descriptions, current prices, inventory, media links, fulfillment details, and other required fields, then validate each delivery and maintain the feed through daily snapshots or API updates.

Q: What product feed does ChatGPT shopping require?
A: ChatGPT shopping requires a secure CSV or JSON product feed with identifiers, descriptions, prices, inventory levels, media links, and fulfillment options. Required fields determine whether price and availability appear correctly, while recommended fields such as additional images and review counts can help with ranking.

Q: How often should I update a product feed for ChatGPT shopping?
A: Merchants should send a full product-feed snapshot at least once per day or use API updates throughout the day. Many teams combine a daily snapshot with API pushes for price and inventory changes, validating the data before every delivery.

Q: Which product-feed fields should block a ChatGPT shopping upload when missing?
A: Missing required fields should be treated as a hard stop before a ChatGPT shopping feed is delivered. Merchants should check every record, with particular attention to stable product IDs, current prices, inventory availability, working image URLs, brand names, category paths, and applicable shipping details.

Q: How should I handle product removals and inventory changes in a ChatGPT shopping feed?
A: Merchants can handle removals by dropping the product record or changing the product’s eligibility flag. Price and stock changes should be pushed through API upserts when available, and every update should be validated to reduce ingestion errors and overselling.

Q: Why is ongoing product-feed optimization needed for ChatGPT shopping?
A: A manually maintained or set-and-forget feed cannot keep pace with catalog changes, specification updates, and shifting ranking signals. Ongoing work can include title and description testing, missing-attribute enrichment, AEO question-and-answer creation, data governance, ingestion monitoring, and daily optimization.

### Why Your Demos Aren't Converting
Source: https://www.lastmilestack.com/writing/why-your-demos-arent-converting
Entities: Current → Desired → Impact discovery framework, Robert Riefstahl, Demonstrating to Win!, solution engineering discovery, revenue-focused technical leaders

The post explains how solution engineers can improve discovery and demos by using Robert Riefstahl’s Current → Desired → Impact framework from Demonstrating to Win!. The author describes how to diagnose workflow friction in the Current state, elicit a customer-defined Desired outcome without prematurely pitching, and quantify business Impact in terms of time savings or revenue lift. The post argues that using this framework in every customer conversation shifts discussions from features to business outcomes, which reduces churn, shortens sales cycles, and positions solution engineers as trusted advisors.

Q: What is the Current → Desired → Impact framework for discovery that solution engineers can use?
A: The Current → Desired → Impact framework for discovery, described in the post and attributed to Robert Riefstahl’s book Demonstrating to Win!, guides solution engineers to first understand how work is currently done and where workflow gaps and friction exist, then uncover the customer’s ideal solution in the customer’s own positive language, and finally quantify the potential impact of that solution on time or revenue. The framework is presented as a way to connect technical depth to strategic impact by moving conversations from feature checklists to business outcomes.

Q: How should a solution engineer ask about a customer’s current state during discovery?
A: According to the post, a solution engineer should ask questions such as “How is your work currently done? Walk me through the gaps in workflow. What systems are you using to get around that?” and then use the answers not just for documentation but to diagnose friction. This approach helps the solution engineer identify the pain behind the process, which the post describes as a key to building urgency.

Q: How do I get a customer to describe their desired outcome without jumping straight into pitching my product?
A: The post recommends asking a question like “What’s your vision or ideal solution?” and then rephrasing that question in different language until the customer describes the ideal outcome in their own words and in positive rather than negative terms. The author emphasizes that the goal at this stage is not to pitch but to uncover what the customer wants fixed, prioritized, and streamlined, while setting up a path to bridge from that desired state to the solution during the demo.

Q: How can I quantify impact in a sales demo as a solutions engineer?
A: The post suggests asking the customer a question such as “If you had a magic wand and this solution was in place, what would be the impact on your time, or better yet, revenue lift?” and using the response to build an ROI narrative. The author states that if a demo does not quantify impact in this way, the solution engineer is leaving value on the table and often losing the deal.

Q: Why does the author think the Current → Desired → Impact framework matters beyond initial discovery calls?
A: The author states that the Current → Desired → Impact framework is a mindset for every customer conversation, not just discovery calls, because it elevates the dialogue from features to business outcomes. The post claims that when solution engineers consistently use this framework, churn drops, sales cycles shorten, and solution engineers become trusted advisors.

### The Demo Crime Files: Are You Guilty?
Source: https://www.lastmilestack.com/writing/demo-crime-files-you-guilty
Entities: Demonstrating to Win!, Robert Riefstahl, The Demo Crime Files, Solutions Engineer, Sales engineering demos

The post summarizes the "Demo Crime Files" concept from Robert Riefstahl’s book "Demonstrating to Win!" and applies it to the work of Solutions Engineers. The post describes five categories of demo mistakes: featuring crimes (showing features instead of solving problems), alienation crimes (using internal jargon that confuses prospects), chameleon crimes (failing to adapt to the customer’s environment and terminology), presenting crimes (losing audience connection through poor delivery and structure), and team crimes (uncoordinated multi-presenter demos). The post emphasizes that most Solutions Engineers have committed these mistakes but that they can be fixed through awareness, preparation, and practice. The post ends by asking readers to reflect on their own demo pet peeves and habits they have unlearned to improve their demos.

Q: What are the main demo mistakes described as "Demo Crime Files" in Robert Riefstahl’s framework?
A: The main demo mistakes described as "Demo Crime Files" are featuring crimes, alienation crimes, chameleon crimes, presenting crimes, and team crimes. Featuring crimes involve demoing feature by feature instead of solving real problems, alienation crimes involve confusing or frustrating prospects by using internal language instead of the prospect’s language, chameleon crimes involve failing to adapt to the customer’s environment, data, or terminology, presenting crimes involve breaking connection with the audience through poor delivery, unclear flow, or missed context, and team crimes involve winging a demo with multiple presenters and no game plan.

Q: What is a "featuring crime" in a sales or solutions demo?
A: A featuring crime in a sales or solutions demo is demoing feature by feature instead of focusing on solving real problems for the prospect. A featuring crime shifts attention to a checklist of capabilities rather than showing how the software creates business impact for the customer.

Q: How does the post define "alienation crimes" during a demo?
A: The post defines alienation crimes as confusing or frustrating prospects by speaking the vendor’s language instead of the prospect’s language. Alienation crimes occur when a presenter uses internal jargon or concepts that do not match how the customer thinks about their own business.

Q: What are "team crimes" in multi-presenter demos?
A: Team crimes in multi-presenter demos are mistakes that happen when multiple presenters run a demo without a clear game plan. Team crimes typically show up as an uncoordinated flow, handoffs that feel improvised, and a lack of preparation across the demo team.

Q: According to the post, can these demo "crimes" be fixed, and if so, how?
A: According to the post, the demo crimes described in the "Demo Crime Files" can be fixed through awareness, preparation, and practice. The post states that most Solutions Engineers have committed these mistakes, sometimes without knowing, but that deliberate effort in recognizing and addressing them can significantly improve demos.

### Rapid Proof-of-Concept Delivery in SaaS: Strategies for Tight Timelines
Source: https://www.lastmilestack.com/writing/rapid-proof-of-concept-delivery-saas-strategies-tight
Entities: Rapid SaaS proof-of-concept (PoC) delivery, Enterprise SaaS sales PoC strategy, Solutions Engineering PoC playbooks, Fast-track PoC scoping and success criteria, Iterative PoC development with agile practices, Cross-functional collaboration between Solutions Engineering, Product, and Engineering for PoCs

This post explains how SaaS solutions and sales engineering teams can run rapid, focused proofs-of-concept (PoCs) that close enterprise deals faster. The post emphasizes time-boxed PoCs of roughly two to six weeks, ruthless scoping around one or two critical use cases, and clearly documented success criteria tied to buyer pain points. The post describes using rapid prototyping, mockups, and cloud-based demo environments to accelerate delivery, while relying on iterative development with frequent stakeholder check-ins to maintain alignment. The post also highlights close collaboration with product and engineering teams, the use of structured PoC playbooks, and real-world examples where fast-track PoCs improved win rates, shortened evaluation cycles, and increased deal sizes.

Q: How long should an enterprise SaaS PoC run to keep momentum without dragging on?
A: An enterprise SaaS proof-of-concept should typically be time-boxed to roughly two to six weeks to maintain urgency and stakeholder engagement. The post contrasts this with more traditional 90-day trials and notes that many SaaS teams target about 30 days, with explicit commitments such as delivering a defined outcome within a three-week sprint. The examples in the post include a 14-day evaluation cycle and a tightly scoped 10-day PoC, which both supported faster decisions. The key is to set a firm, short timeline that is agreed by all parties and reinforced through milestones and regular check-ins.

Q: How should I scope a SaaS PoC so it does not spiral out of control?
A: A SaaS proof-of-concept should be scoped by defining one primary goal, keeping use cases narrow, and explicitly documenting what will and will not be addressed. The post recommends aligning objectives with specific buyer pain points, such as proving an integration or demonstrating a measurable outcome like reducing a manual workflow by 50%. Solutions Engineers are advised to create a brief PoC proposal that captures scope, timeline, success metrics, and team responsibilities, and to get explicit agreement to prevent scope creep. Additional feature requests should be captured for future phases, and unrealistic KPI targets should be reframed as validation tools rather than hard commitments.

Q: What are practical ways to move faster when building a SaaS PoC UI or workflow?
A: To move faster when building a SaaS PoC UI or workflow, the post recommends using rapid prototyping with existing tools, templates, and low-code solutions instead of building everything from scratch. For features that are not production-ready, the post suggests creating clickable mockups or slide-based demonstrations, while clearly communicating which elements are conceptual and on the product roadmap. Cloud-based sandboxes, templates with AI-generated mock data, and virtual environments that mirror customer infrastructure are highlighted as ways to reduce setup time, with cloud demo environments cited as cutting setup time by approximately 50%. Including product managers and engineers in customer meetings helps convey the product vision without waiting for full development.

Q: How should a Solutions Engineer run the execution of a rapid PoC day to day?
A: A Solutions Engineer should run a rapid PoC as a mini-project with short iterative cycles, tracked tasks, and frequent customer touchpoints. The post recommends breaking the PoC into mini-milestones, using weekly or even daily builds, and holding weekly or bi-weekly sync meetings to showcase progress, gather feedback, and confirm next steps. This cadence allows real-time course corrections and ensures that by the final deadline there are no surprises because customer stakeholders have effectively participated in the build process. Treating the PoC as an iterative collaboration rather than a one-time demo helps maintain momentum and alignment throughout the engagement.

Q: What impact can a well-run fast-track PoC have on win rates and deal size?
A: The post describes a mid-sized DevSecOps-focused cybersecurity company that used a presales platform and fast-track PoCs to increase win rates from 50% to 65% and reduce evaluation duration by 16%, cutting about two days from a typical 14-day cycle. The post also cites a B2B analytics firm that executed a tightly scoped 10-day PoC for a retail chain using actual sales data, which produced a 33% improvement in forecast accuracy and a deal that was double the original projected size. These examples illustrate that disciplined, rapid PoCs can both accelerate decisions and improve commercial outcomes when they are focused on clear metrics and real customer data. The post further notes that a structured PoC playbook helps avoid slow, chaotic trials and leads to more timely conclusions and fewer stalled deals.

### Technical Storytelling in Sales
Source: https://www.lastmilestack.com/writing/technical-storytelling
Entities: Technical storytelling in sales engineering, STAR (Situation, Task, Action, Result) storytelling framework, Story bank for pre-sales teams, Anonymized customer case studies, Pre-sales technical demos and objection handling

This post explains how technical storytelling helps sales engineers move beyond feature demos to narratives that resonate with customers and help them envision success. The post recommends building a shared, anonymized story bank based on real customer case studies, structured with the STAR (Situation, Task, Action, Result) framework. The post outlines when to use stories in pre-sales, such as clarifying features, guiding demo walkthroughs, and handling objections. The post also provides concrete examples from healthcare and fintech to illustrate how structured stories highlight problems, solutions, and measurable outcomes.

Q: How should a sales engineer use technical storytelling instead of just listing product features?
A: A sales engineer should use technical storytelling by turning product features into narratives that show how real customers solved specific problems and achieved measurable outcomes. The sales engineer can frame each story with a clear situation, the task that needed to be accomplished, the actions taken with the solution, and the resulting impact, so that prospects can envision their own success with the solution.

Q: What is the STAR framework in a sales engineering context and how do I apply it?
A: In a sales engineering context, the STAR framework structures a story into Situation, Task, Action, and Result. A practitioner describes a relatable customer problem as the situation, clarifies what needed to be accomplished as the task, explains how the solution was implemented as the action, and closes with specific outcomes such as efficiency gains or uptime improvements as the result.

Q: How can I build and maintain a useful story bank for pre-sales conversations?
A: A useful story bank for pre-sales conversations can be built by creating a shared Slack channel or internal forum where teams regularly post and discuss successful customer stories, using a simple template that captures customer or category, problem, solution, outcome, and anonymity status. The story bank should be maintained through recurring team reviews that update stories for relevance and accuracy and remove stories about churned customers.

Q: How do I handle customer references when I cannot name specific customers in my stories?
A: When specific customers cannot be named, a sales engineer should keep stories anonymous by referring to customers with descriptive tags such as a leading fintech firm or a regional health system instead of explicit names. The sales engineer can still describe the industry, problem type, use case, and measurable results so that the story remains concrete and credible without exposing identities.

Q: When in the pre-sales cycle should I use customer stories to be most effective?
A: Customer stories are most effective in pre-sales when they are used to clarify feature requests by showing how other customers achieved results, to enrich demo walkthroughs by tying features to discovered pain points, and to handle objections by sharing examples of similar clients overcoming comparable concerns. Using stories at these moments helps prospects connect technical capabilities to outcomes that matter to their own situations.

### Is AI Replacing Your Software Engineering Customers?
Source: https://www.lastmilestack.com/writing/ai-replacing-your-software-engineering-customers
Entities: Microsoft, Google, YC Hacker News, software engineers, sales engineers, technical buyers

This post explains how increasing AI-generated code, now over 30% according to Microsoft and Google, is changing the role of software engineers and how sales and solutions engineers should adapt. Software engineers are using AI to handle repetitive coding tasks so they can focus on higher-level, high-leverage engineering work rather than being replaced. The post argues that sales engineers need to shift their narrative toward reducing decision load, understand where AI still falls short in areas like debugging and integration, and respect technical buyers’ time with precise, well-researched conversations. The post reframes solutions engineering as context engineering, where the key value is aligning a solution with the evolving workflows and strategic priorities of engineering buyers.

Q: Is AI actually replacing software engineers or just changing their work?
A: According to the post, AI is not replacing software engineers but is instead taking over the repetitive "grunt work" of coding so that engineers can focus on higher-level, high-value engineering problems. The post cites discussions on YC's Hacker News where engineers report that AI is replacing the parts of their jobs they never liked, which shifts their attention toward more strategic and complex work.

Q: How much of new code is currently AI-generated according to this post?
A: The post states that, according to Microsoft and Google, over 30% of new code is now AI-generated, which is an increase from about 25% just a few months earlier. This statistic is used to illustrate how quickly AI-assisted coding is being adopted in software engineering workflows.

Q: What should sales engineers change in their approach when selling to engineering teams using AI?
A: The post advises sales engineers to shift their narrative from offering more tools to reducing decision load, positioning their solution as an accelerator for high-leverage engineering work rather than just an automation layer. Sales engineers are encouraged to understand where AI still struggles, such as debugging, system integration, and edge cases, and to use those friction points as anchors in conversations while demonstrating precise, well-researched understanding of the buyer’s context.

Q: Where does AI still fall short for software engineers according to this post?
A: The post explains that AI performs well at generating boilerplate code and speeding up prototyping but often falls short in debugging, system integration, and handling edge cases. These shortcomings are described as areas where engineering pain accumulates and where sales engineers can anchor value when discussing solutions with technical buyers.

Q: What does the post mean by saying solutions engineering is becoming context engineering?
A: The post describes solutions engineering as context engineering because AI is increasingly handling the "what" of code generation, while engineers and sales engineers must focus on the "why" and the broader context. In this framing, the primary responsibility of a sales engineer is to connect a solution to the buyer’s evolving workflows and strategic priorities, building trust by deeply understanding daily engineering work and uncovering real technical pain points.

### The SE Secret Weapon: Relationship Building for Sales Growth
Source: https://www.lastmilestack.com/writing/se-secret-weapon-relationship-building-sales-growth
Entities: Solutions Engineer, Account Executive, Enterprise sales, Land-and-expand opportunities, Magic wand sessions, Private hackathons

This post argues that a Solutions Engineer’s technical expertise and relationship network can be a major driver of enterprise revenue when used intentionally alongside traditional sales cycles. The author describes how Solutions Engineers can build trust with influential technical stakeholders outside the formal buying committee, gather intelligence from sources like open-source repositories and job listings, and surface land-and-expand opportunities to account executives. The post recommends tactics such as informal coffee conversations, magic wand sessions, and private hackathons to uncover needs and co-create solutions with customers. The author emphasizes that this approach requires close alignment with account executives so that Solutions Engineer–driven relationships accelerate deals and reduce churn without operating independently from the sales team.

Q: How can a Solutions Engineer use personal technical relationships to drive more enterprise sales?
A: A Solutions Engineer can use personal technical relationships to drive more enterprise sales by building direct connections with influential technical stakeholders who are not on the formal buying committee and using those relationships to uncover new needs and initiatives. By having informal conversations, sharing knowledge beyond the specific product, and maintaining ongoing contact, the Solutions Engineer can surface land-and-expand opportunities and bring those opportunities to the aligned account executive as potential deal expansions or new projects.

Q: What specific tactics can a Solutions Engineer use to uncover hidden opportunities inside an existing customer?
A: A Solutions Engineer can uncover hidden opportunities inside an existing customer by scheduling informal coffee chats with technical counterparts, proposing magic wand sessions to explore ideal solutions, and organizing private hackathons that involve both the vendor and customer engineering teams. These activities create space for customers to articulate deeper needs, reveal organizational priorities, and expose potential synergies with other groups, which the Solutions Engineer can then translate into concrete opportunities for the sales team.

Q: How can a Solutions Engineer gather useful deal intelligence outside of formal sales cycles?
A: A Solutions Engineer can gather useful deal intelligence outside of formal sales cycles by monitoring open-source repositories and company job listings to detect emerging priorities and upcoming initiatives before they become formal projects. Combined with ongoing conversations with technical contacts, this pattern recognition allows the Solutions Engineer to identify potential needs early and proactively position solutions with the account executive, sometimes ahead of competitors.

Q: What does the post mean by the 'conversational ask' for Solutions Engineers, and how should it be used?
A: The post defines the 'conversational ask' for Solutions Engineers as a low-pressure way to request time and information from technical stakeholders, framed around staying informed and exploring potential synergies rather than pushing an active deal. Examples include saying that part of the Solutions Engineer’s job is to keep up with how the customer is approaching a particular goal and offering to buy coffee to hear their perspective, or referencing work with another group at the same company and suggesting a conversation about possible overlaps that could benefit the stakeholder’s team.

Q: How should Solutions Engineers coordinate with account executives when using their own relationships to influence revenue?
A: Solutions Engineers should coordinate with account executives by treating relationship-building and intelligence gathering as a collaborative effort rather than acting independently from the sales team. The post emphasizes that Solutions Engineers need clear alignment and communication with account executives so that insights from technical networks are used to accelerate deals and mitigate churn in a way that supports, rather than conflicts with, the broader account strategy.

### StackOverflow Developer Survey '24 Results
Source: https://www.lastmilestack.com/writing/so-24-results
Entities: 2024 Stack Overflow Developer Survey, Stack Overflow, SaaS, AI tools, Technical documentation

The 2024 Stack Overflow Developer Survey indicates that developers rely heavily on online resources and technical documentation, while many already use AI tools without viewing AI as a job threat. SaaS sellers targeting software engineers should provide technical documentation and support, demonstrate time-saving value, address concerns about AI and job security, and account for a growing demographic of developers aged 35 and older.

Q: How do developers learn to code according to the 2024 Stack Overflow Developer Survey?
A: According to the post's summary of the 2024 Stack Overflow Developer Survey, 82% of developers learn to code through online resources, compared with 49% who learn in school. Technical documentation is the leading learning resource, followed closely by Stack Overflow.

Q: What should SaaS sellers prioritize when selling to developers?
A: SaaS sellers targeting developers should prioritize technical documentation and support, time-saving capabilities, and efficiency. SaaS sellers should also address concerns about AI and job security and build empathy with older, more experienced developers.

Q: Do developers see AI as a threat to their jobs?
A: The post reports that 70% of professionals disagree that AI threatens their jobs, while 62% already use AI tools. The post identifies salary decreases, rather than AI-related displacement, as the leading concern.

Q: Which developer roles saw median salary decreases?
A: The post identifies blockchain developers and site reliability engineers as examples of roles with declining median salaries. The post does not provide the size of the decreases.

Q: What developer demographics should tech sellers account for?
A: The post says most developers remain full-stack or back-end engineers despite economic challenges. The proportion of developers aged 35 and older is growing, so tech sellers should account for older, more experienced practitioners.