Voice AI has taken the world by storm in 2024, becoming one of the most compelling use cases for AI technology. When combined with text-based channels, the technology will quickly upend the $3T contact center industry enabling every interaction between businesses and consumers to be mediated by AI.

In the fall 2024 batch, 22% of YC companies in the latest batch are voice-native—a remarkable increase from just 6% a year ago. Large model labs have begun to invest significantly in this interaction platform, with OpenAI and Google DeepMind releasing real-time voice mode and Gemini Flash 2.0, respectively. Smaller labs like Eleven Labs and Cartesia are also investing significantly into powerful voice-native experiences, increasing the quality of voice native experiences built atop of their platforms.

Why Voice-to-Voice Models are the Next Frontier

In 2025, voice-to-voice models are emerging as a transformative technology in the field. Traditional voice pipelines rely on a sequence of speech-to-text, processing by a large language model (LLM), and text-to-speech synthesis. Like with any high-performance machine learning system, voice-to-voice allows practitioners to minimize the compounding error rate which can arise from a multi-model architecture. Voice-to-voice models have a few characteristics that drastically improve customer satisfaction over previous voice pipeline approaches.

1. Improved Accuracy for Critical Information

   Traditional pipelines often falter when tasked with transcribing precise information like email addresses, phone numbers, or alphanumeric codes. These approaches require lightning-fast transcription models that often cannot grasp the broader context of what a user is saying. In contrast, speech-to-speech models, undergirded by a large language model (LLM), can intuit key transcription details more effectively, much like a human might when understanding speech. These challenges compound in languages with phonetic or tonal complexities, for which transcription data is scarce precluding agents from a wide set of use cases.

2. Reduced Latency and Simplified Infrastructure

   By eliminating the need for multiple service calls—speech-to-text, LLM processing, and text-to-speech—voice-to-voice models drastically lower latency. This reduction is particularly important for real-time applications like customer support or conversational interfaces, where delays can degrade user experience. Additionally, this reduced latency simplifies infrastructure requirements; if you're only calling one model, you don't need to worry about collocating various steps of the voice pipeline.

3. Enhanced Conversation Satisfaction Through Mirroring

   One of the most compelling advantages of voice-to-voice models is their ability to mirror a user’s speech patterns. This mirroring—whether through tone, pacing, or inflection—enables more natural and engaging interactions. Such capabilities are particularly valuable for use cases like sales, where building rapport is key, or in sensitive customer support scenarios, where empathy and understanding are critical. Voice-to-voice models retain nuanced elements of speech, such as emotion, tone, and prosody components which are all lost with traditional voice approaches.

Existing Limits to Voice-to-Voice

While voice-to-voice models offer transformative potential, there's a reason we don't see broader adoption of the approach in a number of production use cases.

1. Content Moderation: Content moderation remains a critical concern for enterprises adopting voice-to-voice models. Ensuring that speech outputs align with company guidelines or avoid inappropriate content is inherently challenging without a text intermediary. Companies like OpenAI have pioneered live content moderation solutions, transcribing real-time speech outputs to flag and halt inappropriate conversations immediately. In sensitive domains, like healthcare and law, voice agents need strict guardrails to restrict agents from dispensing medical advice or hallucinating company policies.

2. Reasoning/Speed Trade-offs: Voice agents have historically faced trade-offs between reasoning speed and accuracy, particularly in complex function calls or multi-step tasks. These capabilities are crucial for voice agents to replace agents in a variety of domains. However, current systems still grapple with delivering consistent logical coherence at real-time speeds.

3. Cost and Reliability: Until recently, cost has been a significant barrier for scaling voice-to-voice agents. For example, OpenAI’s real-time API historically cost $0.09 per input and $0.24 per output, amounting to nearly $9 per hour—comparable to a human call center agent in regions like the Philippines. This cost structure has limited widespread use, particularly for smaller businesses or organizations operating at scale.

In 2025, however, there's definite optimism that many of these issues will be solved. Voice-to-voice content moderation is quickly becoming a solved problem, thanks to rapid and accurate transcription models. Real-time content moderation works by immediately stopping speech play-out if inappropriate content is detected. Companies like OpenAI implement this using transcription models in their advanced live mode and real-time API. As transcription models become faster, there is potential to introduce a voice-native moderation layer, enabling seamless and proactive moderation directly within the speech pipeline. Below is a brief diagram for how this is typically implemented.

"Fundamental equations" balancing reasoning speed, cost, and realism have also transformed significantly towards the end of last year. Improved instruction-following performance in smaller models (such as Llama 3.3 70B and OpenAI's GPT-4o-mini) has unlocked new opportunities for voice-to-voice agents. These agents, built on platforms like OpenAI's realtime-mini or Fixie AI's Ultravox, demonstrate impressive capabilities in completing multi-step reasoning tasks. Parallel approaches used to disambiguate function calling and dialog enable agent builders to skirt this trade-off entirely.

Voice-to-voice models are coming down significantly. Competition between OpenAI's Realtime API and Gemini's Flash 2.0 model produces yet another win for builders at the application layer. The newest OpenAI Realtime-mini model now clocks in at an average hourly cost of 90 cents per hour, unlocking feasibility for voice for a number of high-volume use cases.

Looking Ahead

Voice-to-voice AI represents a pivotal advancement in the evolution of conversational technologies. By addressing challenges like content moderation, reasoning accuracy, and cost, these systems are paving the way for broader adoption across industries. The innovations seen in 2024 and 2025 have laid the groundwork for practical, scalable voice AI solutions, enabling applications from customer support to high-sensitivity domains like healthcare. As costs decrease and capabilities improve, voice-to-voice systems are no longer just a promising idea but a practical reality reshaping human-computer interactions. Organizations investing in this technology now stand to gain a significant edge as the field matures.

The rearview mirror

The first decade of venture funded “freight tech” could be characterized in many ways, but few would say it’s been uneventful. $100B have been poured into digital freight brokerages, virtual carriers, next generation fuel cards, and tech-enabled freight forwarders. The terminal value of these investments has yet to be proven; though the bankruptcies, restructurings, and business model pivots paint a particularly grim outlook. “Pure software” plays for an individual LSP category (carrier, broker, or freight-forwarder) are simply sub-scale for venture investment, while approaches entirely dependent on spot market GMV are sensitive to freight’s violent demand cycles.

Despite the wreckage in the rearview mirror, it’s hard not to be excited about the road ahead. Over-the-road freight is still a $400B industry, with an estimated $40B of non-driver operational expense spend. Core operational workflows such as quoting, billing, and tendering still occur largely over email or phone. The unbundling of the transportation management system (TMS) presents ripe opportunity for complex workflow automations, living atop the previously impenetrable source of truth. Generative AI enables the digitization of natural language workflows, only recently tractable for incumbent software vendors.

The road ahead

How will the next decade be any different than the last? What opportunities expand beyond meager LSP IT spend without reliance on a marketplace take rate?

AI eats OPEX

One answer has been to build software that competes directly against labor costs. It’s become vogue to build product surfaces mimicking communication with real employees to avoid the typically long implementation and training cycles for vertical SaaS. For many LSP workflows (appointment scheduling, quoting, billing, etc.) overseas outsourcing is already commonplace. These tasks are ripe to be replaced with customized, deterministic, LLM-native applications. They largely involve repeatable execution on a pre-defined set of steps, analyzing unstructured documents and human communication.

While productivity tooling for LSPs is an enticing product opportunity, it remains unclear whether it’s venture scale. A typical brokerage might achieve net revenues of 15%, of which 70% is spent on personnel (~%10 of total). Of this massive headcount budget, 80%, is spent on “high value” tasks: attaining and building relationships with carriers, warehouse owners, and shippers. 20% (~2% of total) is spent on tedious “back office” tasks like appointment scheduling, quoting, load building, document collection, and billing. In aggregate, this is $3.2B of total addressable spend, from the $160B US 3PL industry. Carrier businesses operate similarly, a 10-truck carrier can spend 170K$ outsourcing administrative tasks such as dispatching, tendering, and accounting.

Monetizing freight volumes

While many freight software categories remain highly fragmented with low NPS, the US LSP market is simply subscale for venture outcomes. Attractive freight-tech opportunities directly monetize of shipper freight procurement ($1.3 trillion of US spend) rather than subscription revenue from an individual category. Winning opportunities will facilitate a core data flow for a plurality of freight volume and will monetize with transaction processing or supply chain financing. The sheer variety of counterparties participating in a freight transaction (shippers, forwarders, brokers, and LSPs) allows entrepreneurs to monetize multiple “turns of the dollar”. Each “leg” of the payments journey from shipper to carrier can compound the percentage take of a payments network business.

The “10 billion dollar freight tech that was promised” likely combines these two approaches to construct an entirely novel business model. It will digitize complex and unstructured activity between LSPs and their customers, converting manual back-and-forths into standardized remote procedure calls.

The opportunity in payments

The biggest opportunity to build than integration layer likely exists in billing and payments. This is a business-critical workflow for any high volume LSP and is rarely a “core-competency”. While “pre-delivery” workflows completed by “front-office” staff have been a primary focus for most LSP software offerings (quoting, load building, track and trace), “post-delivery” actions taken after a load “is transferred to accounting” are distant landmarks on most freight tech roadmaps.

It’s often joked that the most common refrain in logistics is “where’s my stuff”, in reference to the critical freight challenge of shipment visibility. The second most common is “where’s my money”. Invoicing for freight services is an operational nightmare, for a number of reasons:

• Extreme customer fragmentation requires LSPs to support various invoicing flows, leveraging shipper portals, billing through EDI, over email, even by fax or post.

• To generate an invoice, carriers and brokers must retrieve proof of delivery (PODs) from drivers upon delivery at a facility, which satisfy stringent shipper requirements (so far, I’ve seen dozens: documents are required to be scanned, consignee signatures must be circled, all PO identifiers must be legible, etc.). Brokers often bill large shippers in batches of 50-100 shipments, so a single error invalidating a bulk invoice can debilitate 3PL cashflows.

• Invoices can include nearly hundreds of miscellaneous charges: carriers can face deductions by failing to track their trip, brokers payout detention **for every hour past an appointment that a carrier waits at a facility, food distributors charge “claims” for fruit spoiled by trailers from minor deficiencies in trailer refrigeration. These “accessorial” charges require detailed unstructured evidence (in-and-out times, receiver notes) to audit and dispute.

• Freight payment is often as disordered as billing. Brokers, forwarders, and shippers pay vendors via check, credit card, wire, or ACH. Payers send remittances in a variety of formats and will even mail invoices back to their vendors as a payment notification. Large shippers and brokers will often make payments in bulk, requiring LSPs to stitch together extensive balance reports to accurately reconcile incoming payments.

• Most load volume between carriers and brokers is paid by invoice factoring companies. In order for these companies to release a single payment, an operator at a factoring company needs to converse with an operator at a brokerage to verify that the carrier will be paid the invoiced rate, that all documents submitted by a carrier are entirely valid, and that released payment will go to the correct party.

Every manual verification and translation step between members the 4 counterparties of freight procurement (carriers, 3PLs, factors, and shippers) present a transactional monetization opportunity. Transportations factors will pay outsourced agents $1-3 for each invoice they successfully verify, LSP outsourced collections departments can cost 2-4% of net revenue, and shippers can collect high-margin “quickpay” revenue from LSPs, accelerating vendor payment for a percentage of total transportation volume.

A particularly exciting wedge into payments communication is the arduous process of invoice verification for LSP factors. Nearly $90B of freight spend (70% of 3PL volume) is processed by transportation factors that charge 2-3%, smoothing carrier cashflows. Millions of dollars of operating expense is spent between factors and brokers to confirm the amounts of individual invoices. Automating this communication end-to-end had previously been impossible due to extreme counterparty fragmentation. Everyday hundreds of transportation factors work with thousands of brokers using dozens of bespoke TMSes. Recent advancements in LLMs allows a software player to rapidly digitize manual communication over email, phone, and web portal bootstrapping a payments network for instant verification of every load.

The “clearinghouse” for freight

The opportunity to digitize logistics payments communication parallels the rise of healthcare clearinghouses, which charge a per transaction fee for communication between tens of thousands of providers and tens of thousands of payers. Fragmentation in that industry made invoicing, payment verification, and reconciliation painful for businesses giving rise to massive software opportunities like Waystar, Change Healthcare, and Optum. A similar approach in freight yields a similar opportunity to standardize the transmission of accounting information between industry parties. Just as healthcare clearinghouses established a foothold with claims submission, before extending to prior authorization, denial resolution, and payment posting, a “clearinghouse for freight” has the opportunity to “land” in load verification and “expand” into remittance processing and dispute management.

Clearinghouses and payment processors fundamentally rewrote business processes by allowing the transfer of value to move digitally alongside the transfer of money. Insurmountable software fragmentation previously prevented this innovation from reaching supply chain. As the barriers for digitizing unstructured communication begin to fall, opportunity arises for the right team to build a massive defensible network business.

If this opportunity is as exciting to you as it is to me and you’d like to chat more, reach out to Ken Acquah.

TruckSmarter builds product with no PMs. Instead, we expect operators and builders to directly define the specifications of products they work on and with everyday. Below I “open source” an internal piece I wrote to discuss the “skill” of defining product requirements.

At TruckSmarter, we plan product development with a number of documents: we use product proposals to light the first spark of product ideas, we use engineering requirement documents to discuss the appropriate technical approach for executing on a particular feature, we use Figma designs to detail exactly how a user flow will progress once a particular feature is incorporated in any of our user-facing applications. Most critical amongst these documents is the “product requirement document” (PRD), which details the precise requirements of a particular product or feature. Building a successful software product is a collaborative effort between a wide range of functions: legal, marketing, operations, sales, etc. Product requirement documents are crucial for ensuring every individual involved in this effort is aligned on the what and why of any product development initiative.

Why should you read this?

At TruckSmarter, we don’t have a typical “product manager” role. We entrust operators and builders to directly define the specifications of products they work on and with everyday. This unique operational style has empowered individual contributors to quickly ship high impact product updates and maintain an execution advantage, relative to competitors. This organizational structure only works if all individual contributors can confidently define product requirements for the initiatives they accomplish.

What is a product requirement document?

The simplest definition of a product requirement document perhaps lives within its name: A product requirement document is a document that should detail all product requirements of a feature. This definition is straightforward, but is perhaps not complete enough to be particularly useful. Ambiguity in its individual words minimizes its utility.

• “all” doesn’t clarify the scope of the document. Surely this document doesn’t need to include a pixel by pixel specification of every sub-component of the feature?

• “product requirements” doesn’t clarify the concerns of the document. How do I know which requirements are properties of the “product” as opposed to the “design” or the “engineering architecture”?

• “detail” doesn’t clarify the form of the document. What if I want to include wireframes or flow charts when communicating requirements?

A more technical definition, borrowing from established standards on the practice of project management provides more informative guardrails of what should and shouldn’t be in a product requirement document.

A product requirement document details all functional requirements of stakeholders for a particular feature.

Like any good definition, this motivates a few more sub-definitions.

• Functional requirements refer to the expected behaviors of the feature once it is completed from the perspective of project stakeholders.

• Project stakeholders are the set of persons or entities who may affect or be affected by the outcomes of a project. Stakeholders are often, but not exclusively, team members at a software development company. At TruckSmarter these persons or entities can be carriers, brokers, fuel merchants, the finance team, TruckSmarter’s business, or engineers on a particular on-call rotation.

• A feature is a distinct capability or functionality within a product that provides value to project stakeholders.

With a thorough understanding of the “What?” for product requirement documents, the next question to answer is “who?”.

Who participates in a PRD process?

In order to talk productively about the PRD process, we’ll need to specify its 3 major participants. Each participant plays a different role in crafting a PRD to achieve its goals.

• Project owner: This is the person(s) who is accountable for the writing the PRD, sharing it with reviewers, and for the overall execution of project priorities. This person is distinctly responsible for the success or failure of the project. They “captain” the PRD process; working with other participants to ensure the document achieves its main objectives.

• Stakeholder representatives: These are representatives of PRD project stakeholders that are internal members of the project owner’s organization. While these individuals typically work alongside the project owner, they can represent project stakeholders outside of the project owner’s organization, such as business partners or end-customers.

• Product development team: These are team members at a company (designers, engineers, data analysts) who will be responsible for implementing a feature described in an ERD.

Often times, the same person(s) can take on multiple of these roles (for example, at TruckSmarter a member of the product development team is often a project owner). The project owner authors a PRD, while stakeholder representatives and the product development team are reviewers of the document. Reviewers are expected to review every detail in the “final draft” of the document before beginning significant development, as well as any iterations upon this draft generated throughout the course of product development.

Why do we write PRDs?

Why is it so crucial to write functional requirements down? A product requirement document typically has the following core objectives in descending order of priority.

1. Aligning stakeholder representatives and project owners on the minimal set of functional requirements necessary to achieve a major goal for project stakeholders (which should be spelled out within the document).

2. To give a feature’s development team a source of truth for functional requirements as they bring the feature into existence.

3. To give stakeholder representatives (oftentimes coworkers of a project owner) an artifact describing exactly what the impending effects of the feature might be in order to coordinate any other organization-wide changes associated with a feature (updates to legal documentation, sales materials, or operational processes, etc.).

This list of goals is deceptively brief, but well-written PRDs contain a surprising amount of detail to achieve all three of these objectives. For any sufficiently complex product initiative, project owners must align project stakeholders on a solution that achieves their various goals, track down all details required to inform design and engineering implementation, and define all functional details of a feature that might directly or indirectly affect any individuals (often kicking off a vicious cycle to re-align on product details missed with their first solution). At smaller companies this challenge is heightened with quickly shifting priorities, underdefined product direction, and a rapid execution cadence.

What should I include in a product requirement document?

After “what?”, “who?”, and “why?”, the next question we must answer with regard to a product requirement document is “how?”. Unfortunately, “detail all functional requirements” is not sufficiently descriptive instruction. Below is a non-exhaustive list of “do’s” and “don’t’s” which guide what should be included in a well-defined product requirement document.

• Do center a PRD around the goal of a feature. The first objective of a PRD is to ensure a feature achieves a particular goal for project stakeholders. All discussion between reviewers and authors will revolve around whether or not each functional requirement furthers the documents stated goal. Clearly defining a goal is crucial for a successful PRD process, as it prevents unwanted requirement creep beyond the intended scope of a project owner. Any functional requirements deemed unrelated (or actively harmful) to the goal of a feature should be excluded in the final iteration of the document.

• Do describe functional requirements with enough detail to be useful. The perfect PRD includes all information necessary to achieve the document’s core objectives and not a word more. Project owner must be deliberate in their description of functional requirements, including every detail relevant for aligning team members, specifying development work, and documenting feature functionality. They must establish a ubiquitous language of entities, individuals, and concepts related to the feature, to empower clear discussion of a features efficacy. It’s all too common for authors to include too few details, rather than too many (the absence of relevant details is much harder to spot than the presence of irrelevant ones). An approach that starts with abundance is often preferable to one of scarcity.

  Handwavy fluff in lieu of feature specifications can greatly diminish the utility of the document. It leaves reviewers quarrelling over definitions or ill-described stakeholder concerns instead of discussing a feature’s core functional requirements.

  Some examples of useful functional requirements, for the booking feature of an appointment scheduling application would be:

  • Visitors should be able to select a time on an account owner’s calendar by selecting an available timeslot based on the visitor’s time zone. When booking an appointment, visitors must fill out a form specifying their name, email, and any additional information required by the appointment type.

  • After booking, visitors should receive a confirmation email with a calendar invite. Both the user and the visitor receive reminder emails both 24 hours and 1 hour before the appointment.

  • Visitors can cancel or reschedule appointments through links provided in the confirmation email. The system must offer the user the option to set cancellation and rescheduling policies, including deadlines and any associated fees.

  Examples of requirements without enough detail to be useful are:

  • There's a page where users can book times.

  • Visitors can book appointments.

  These requirements are devoid of specificity, prohibiting a reader from understanding their effect on project stakeholders with any precision. The primary goal of an "appointment scheduling” feature is to help visitors book appointments. For stakeholders to evaluate if it meets that objective they must understand additional details: the workflow for appointment booking and the information used to determine available times. These requirements are meaningless to a product development team. They provide no valuable notes on which data from the account owner is necessary to support a visitor's desired flow and no information regarding the data a visitor can read and write to the application.

• Do split functional requirements by their respective stakeholder. Complex features will often have multiple stakeholders, each of which are affected by a set of functional requirements. Documenting these effects from the prospective of each stakeholder can bring exceptional clarity to a completed document. One could organize the example functional requirements of the previously mentioned appointment scheduling application as follows:

  Visitors

  • Visitors should be able to select a time on an account owner’s calendar by selecting an available time slot based on the visitor’s time zone. When booking an appointment, visitors must fill out a form specifying their name, email, and any additional information required by the appointment type.

  • After booking, visitors should receive a confirmation email with a calendar invite. Both the user and the visitor receive reminder emails 24 hours and 1 hour before the appointment.

  Account Owners

  • Account owners should be able to authorize access to their google calendar, to import time slots for which they are available.

  • Account owners should be able to specify which days of the week are open for visitors to book appointments.

• Do document operational requirements for launching the feature. Launching a feature successfully often requires much more than excelling at product development. It can involve appropriate measurement of user engagement or incurred vendor costs, broad updates to go-to-market strategies and operational processes. Effective PRDs detail what must be measured to understand a feature’s success, how the rollout will be completed, and what the process will be for educating internal and external users about the feature.

• Do link to visual aids if they help communicate functional requirements. A PRD doesn’t need to solely comprise of text. Often times functional requirements are best described with visual aids (wireframes, system diagrams, flow charts, etc.). It is completely reasonable to link non-text artifacts in a PRD for team members to review. That said, to make sure that all discussion of functional requirements can be easily referenced, it is crucial for PRD authors to consolidate any comments from team members into a single document.

• Don’t include functional requirements you do not expect to be supported in the final version of the feature. Sometimes, the hardest part of writing a product requirement document is deciding what not to include as every feature can branch in boundless directions. Including non-requirements in this document often hinders its capability to achieve core objective #2. If a product development team is unable to determine which functional requirements must be satisfied and which are goals for a future iteration, the document cannot effectively be referenced as a source of truth specification.

  Of course, no one is clairvoyant. This “don’t” is not a directive for PRD authors to aim to be so. It instead dictates that “stale” functional requirements should be removed from a PRD before proceeding to product development work. Notes on previously proposed requirements, “P2” requirements (nice-to-have’s which stakeholders might want but are not critical to a feature’s success), or a set of features which might be developed in the future should be relegated to an “appendix” or “future work” section of the document.

• Don’t describe more than 2 “milestones” for a feature. It is common for a large feature’s PRD to be broken down into milestones, or small iterations of the feature which provide iterative benefit for stakeholders. With each additional milestone in a PRD, comes additional difficulty in nailing every detail of every functional requirement. Constructing a PRD for a significantly complex feature is a herculean task, why make it harder by attempting to specify feature development work months in advance? By constraining the feature scope to a handful of milestones a PRD author can lessen their burden aligning on and defining long term requirements. Reducing any risk that a PRD needs to be revisited to accommodate newly discovered requirements months in the future.

  It is very reasonable for a PRD to speculate on the functional requirements of a feature’s subsequent iterations. To ensure functional requirements make a lasting impact, it can be crucial to consider future stakeholder goals. Instead of straining to define future requirements, a project owner should document their foresight in a “future work” section of the document. This can communicate any extensions which much be supported by initial feature requirements.

• Don’t include design or technical details. This “don’t” is perhaps the most socialized guidance on PRDs and doesn’t warrant as much discussion. Where lines can get blurred is that it’s perfectly reasonable to inform functional requirements with engineering or design considerations. Estimates of requirement feasibility are a core input towards discovery of any successful solution. A PRD author can thread this needle by only including high level summaries of implementation details, while routing comments on these details to a more comprehensive function specific document.

How should I interact with a PRD template?

Like many software companies, TruckSmarter provides contributors with a template defining what content they should put in a requirement document. A common critique of company-wide templates is that they are rigid and prescriptive. They define an exact set of details a PRD must include; some of which might not be relevant for

• Features of varying contexts. Product requirements for an internal CRM integration vs. an update to an experience for end users

• Magnitudes of scope. Product requirements for a developer tooling change vs. an entirely new subscription offering.

• Number of effected stakeholders. A feature to be leveraged by a single person on an internal team vs. an update which affects stakeholders across the entire company.

In reviewing hundreds of PRDs over the past few years, I’ve come to see this rigidity as a feature, rather than a bug of a well-defined PRD template. If it even needs repeating, its extremely difficult to identify and describe the minimal set of useful functional requirements of a feature. The temptation one might have to ignore an established PRD template can often have disastrous outcomes for the resulting document. A good template is extensively battle-tested to support the communication norms, operational tenor, and shared user personas of a software development organization. It helps project owners reason about which considerations might be important. It aims to ensure that when properly used, the core objectives of a product requirement document are always met.

Perhaps despite this warning, you might still be inclined to take some artistic license when writing a PRD. Perhaps, the existing template is so mistuned to the context of your feature you’re convinced you can write a more effective PRD with a bespoke structure. Perhaps the feature you’re developing is so minor that you’d prefer to use a more paired down version of your company wide template. These objections are all reasonable, but “freestyle” with PRDs at your own risk. If your proposed bespoke PRD layout fails to achieve the core objectives of the document, you may be asked to write it again. Even worse you may not, leaving this failure unnoticed until it adversely impacts the success of your feature.

The PRD process

Thus far, we’ve covered the meat and potatoes of a PRD process, actually doing the hard work of writing the document. However, writing a product requirements document consists of much more than writing product requirements in a document. A PRD typically has an associated process, in which a project owner identifies which persons and entities are stakeholders of their product, selects the set of functional requirements which achieve an agreed upon goal, and refines their description of these requirements to maximize its utility for a feature’s development team. This process is as important to get right as the actual document. As mentioned, the number one goal of the PRD process is to empower team members to align effectively on a feature’s optimal set of functional requirements.

What are the steps of the PRD process?

• A “project” is planned to begin and it is decided that the project owner will write a PRD to ensure its success. All day, everyday, members of a software development team iterate on the functionality of a company’s products; it can be unclear which iterations are worthy of initiating a process, and for which, the additional overhead is too unwieldy.

  The best guidance I can give to this question is somewhat circular. One should write a PRD if they intend to achieve one of the document’s three objectives. Any time a contributor wants to align a team around a core set of functional requirements of a new individual feature, a PRD should be used. The PRD process is most useful when its the sole document used for achieving these objectives, so if you find yourself aligning on how a system should work, what a user should experience, or the details of a feature’s impact in any non-PRD setting, it’s time to start the PRD process.

• A project owner aligns with stakeholder representatives on the goal of the feature. Before even considering the PRD’s functional requirements, a project owner should achieve unanimous agreement on its feature’s described goal. Without this foundation, a project owner risks complete failure in their PRD’s process as their defined functional requirements may stray severely from a goal stakeholders aim to achieve. A project owner can attain goal alignment in various ways. They can present a “draft goal” asynchronously for stakeholder representatives for review or hold a “kick off meeting” where the project owner ideates synchronously with these stakeholders to determine an appropriate feature goal.

• A project owner works to uncover the functional requirements necessary for a successful launch of the feature. Functional requirements arise from understanding a problem experienced by a project stakeholder. Problem discovery can take a number of forms. For features used by end customers, less likely to communicate directly with the project owner, it could entail conducting user interviews or observing quantitative user data. For features used by stakeholder representatives, it can entail a quick discussion (synchronous or asynchronous) to determine exactly what challenges targeted users might face with their workflow today.

• The feature’s stakeholder representatives and product development team are determined. This ensures smooth progression through the PRD process for the project owner. Collecting feedback from these individual participants is a required component of a successful feature launch, making it critical for project owners to identify them early.

• A project owner writes a PRD, documenting the functional requirements of the feature. Perhaps I’ve discussed this at enough length.

• A first draft document is shared with some reviewers, to give early feedback. Tight feedback loops are a hallmark of overperformance in so many domains, and writing product requirement documents is no different. Effective PRD authors are able to put together a “minimally useful” set of functional requirements to start a conversation on what the final set of functional requirements might actually be. Defining a complete first draft PRD empowers reviewers to directly discuss whether specific functional requirements further the goals of a feature, while an ambiguous work-in-progress forces reviewers to participate in the process as authors, clouding ownership of final document details.

• The final iteration of the PRD is shared with stakeholder representatives and the product development team. Once a PRD’s authors and initial reviewers feel as though the document is stable enough for review from all relevant team members, it should be shared out more broadly for comments. PRD review is critical for achieving objective #1 of the document. This step gives stakeholder representatives the opportunity to evaluate whether or not the project will achieve its expected business goals. It also allows members of the product development team to give specific feedback about the feasibility of individual functional requirements.

  At TruckSmarter, our PRD template forces an author to specify “stakeholders” and “product development team members” so that an owner can document whose reviews are necessary to validate functional requirements.

• Notion properties used for members of my team to document the product development team members and stakeholder representatives held responsible to validate all functional requirements.

• All outstanding discussion around the feature is resolved and the product development team can begin implementation. Project owners, stakeholder representatives, and product development team members must agree on all details of all functional requirements to ensure a PRD achieves all of its core objectives. Any unresolved discussion on the document additional risk that the implemented feature fails to achieve an agreed upon goal. A project owner can finalize alignment on the details of their feature, by confirming that every reviewers comment is resolved or documenting the resolution of “open questions” within the document.

• The product development team begins to implement the feature, supporting all agreed upon functional requirements. Finally.

• Changes to the PRD during development are documented to ensure reviewers remain aligned. Feature development rarely goes exactly to plan. Requirements which seemed feasible are discovered to be unmanageable as the product development team moves to implementation. Opportunities appear to ship new requirements with greater impact or to cut existing requirements deemed unnecessary. When updates are made to functional requirements, stakeholder representatives and product development team members must affirm that the update still furthers the goal of the feature, to avoid negative surprises during the reveal of finished work.

  The PRD template at TruckSmarter includes a “changelog” to record re-validation from stakeholder representatives and product development team members. Any meaningful update to the functional requirements of a PRD is documented in this log, alongside the reviewers who were required to affirm this change.

  

• Notion block used to document changes to a product requirement document made during the implementation of a feature.

Conclusion and caveats

This guide aims to serve more as a theory survey than an instruction manual, giving readers a framework to think about how they might construct a PRD process, rather than prescribing how exactly the powerful tool must be used. My hope is that it gives each reader ample direction for crafting a PRD process well-tuned to their complexity of an individual feature and the operating context of a product development team.

Thanks to Nick Faulkner and Dave Ghent for the thorough review and Mac McCann for the expressive header image for this piece. If TruckSmarter’s unique approach to building product is at all interesting to you definitely check out our available roles!

Over the past few years, start-ups in logistics technology have attracted an immense amount of attention, investment, and "thought-leadership" for an industry that's previously escaped the broadening hype cycles of the software ecosystem. In recent years, the enthusiasm has only heightened, as coronavirus induced supply shocks, increasing trade tensions, and mildly comical container ship mishaps have piqued immense interest for the industry amongst the global business community. As supply chain breakdowns send ripples through downstream industries, enhancing frustrations in the day-to-day lives of most workers in the western world, few can help but ogle at these various operational disasters like passerby's on a freeway, staring at a 10 car pile-up. As personal interest snowballed into insightful tweets, investment theses, and genuine, entrepreneurial innovation, a flurry of viral blog posts and podcasts exploring critical pitfalls in the logistics industry sprung to prominence seemingly overnight. The authors of this coverage often wave their hands in the general direction of the heart of these logistics problems, making undoubtedly correct but impractically broad statements about a need for "technological transformation" and "operational efficiency". A few commentators, typically long-time industry experts or investors with skin in the game, dive deeper into the systems thinking approach required to "fix" our deeply broken contemporary logistics infrastructure. Perhaps out of a desire to somehow self-actualize my existence by exacting my influence on a fascinating conversation, I'd wanted to try and give my own more depthful diagnosis of the main challenge impeding the scalability of logistical processes today, and the exact mechanism by which innovation in logistics technology can help the industry inch towards tackling this problem.

But first let's talk Star Trek. I promise, it'll be somewhat relevant.

Beam Me Up, Scotty

In the Star Trek series, the Transporter is an incredibly nifty device capable of instantaneously transporting an object from one location to another, as easily as a smartphone can send a text. As is the case with most good sci-fi, the mechanism of The Transporter is carefully detailed within the show's dialogue. Transporting an object, requires "dematerializing" it into bits of information representing it's entire physical presence, transferring these bits between Transporter devices, and then "rematerializing" the transferred bits in order to spawn the object in a receiving Transporter device. In the show, the Transporter is used in almost every episode, as its immense convenience makes it easy to let characters move seamlessly through worlds without lengthy set-up or exposition.

Of course, the physics of the transporter are entirely impossible, as Star Trek is just a TV show. "Dematerialization" is effectively magic as described, and transferring the number of bits estimated to represent every atom of a person, would require a duration of time longer than the age of the universe. However, The Transporter's promise is alluring for more reasons than its disobedience to the laws of our universe. Its mechanics are largely inspired by network protocols which enable humanity to transfer trillions of bits instantaneously, across the globe, rebuking contemporary conceptions of the ease with which we can move matter. There is typically a stark difference between the user interface of technology that allows one to transfer bits, such as email or apple pay, and that of technology built for use cases that require transferring atoms, such as coordinating a multimodal trip into a city, or shipping a D2C product from a factory in Shenzen to a customer's apartment in Brooklyn. This immense contrast between the technology suites enabling physical and digital transportation makes a machine that can immediately move goods and people even more enticing, as it unlocks the infinite potential achieved when one can move atoms just as easily as one can move bits.

Today, "bits" are so easy to move as a result of painstaking investment in layers of communication protocols, critical technical infrastructure connecting anything (and everything) with a chip to variety of systems capable of processing immensely complex data. Apple Pay is such an effortless transaction, only as a result of the immense effort poured into developing protocols for communicating between NFC chips and applications, between applications and cloud servers, as well as between cloud servers and on-premise servers hosted by banks. The secret sauce at the foundation of this innovation is inter-operability, the standardized communication between the dozens of parties required to settle a financial transaction from a physical device. The prominence of innovation accelerating inter-operability is hardly restricted to financial technology; similarly standardized communications empower builders within industries such as healthcare, commerce, and the capital markets. Traditionally, inter-operability of logistics and transportation technology, has left much for wanting, which was a significant obstacle preventing anyone from building anything even close to resembling a Transporter. However, there has been a flourish of developments within logistics technology infrastructure in the past few years, suggesting that moving atoms, as easily as one can move bits, might soon not entirely be science fiction.

Where We Are

Before venturing "where no man has gone before", it'd be quite useful to discuss what the state of logistics technology is today. Suppose I owned a clothing brand, and wanted to ship a product from a manufacturing plant in Shenzen to a customer's apartment in Brooklyn. I'll need to coordinate (or pay someone to coordinate) a truck to transport my goods from the plant to Shenzen's port, from the port's loading dock to a particular cargo ship, from that cargo ship to a port in LA, from LA to a distribution center in Newark and from Newark to the customer's home address. Each individual leg of this trip is completed by a carrier, or a company responsible for transporting goods from one place to another.

Carriers come in all shapes and sizes, and often specialize in a variety of transportation modes; truckload carriers transport volumes of goods over the road that are large enough to fill a 53’ trailer, and ocean carriers manage container ships that haul millions of pounds of cargo between continents. Some carriers are international enterprise behemoths like Maersk, the largest container ship carrier in the world, or FedEx, a massive business focused on shipping individual packages that arrive at a consumer's doorstep. Others, are small local operations, perhaps run by a husband and wife duo who own a single truck and maintain a handful of customers, or an exporter working specifically on shipments out of a particular port city in China into another in the United States. Shippers, companies that need wish to move goods between two points, will either contract directly with carriers to procure logistics services, or leverage intermediaries such as brokers and freight forwarders, which subcontract carriers for them. The market for many services in the logistics industry is immensely fragmented, and carriers are rarely capable of integrating with the hundreds of counter-parties they may work with in a given year. The immense fragmentation of actors in the logistics ecosystem begets similar fragmentation of the software solutions they rely on, and thus it is an understatement to remark that the technological infrastructure for moving goods is significantly less efficient than that of sending an email.

Let's dive deeper on the technological innovation that has revolutionized logistics in recent years. Contrary to dominant narratives about the industry, companies that operate at each leg of this journey have made deep investments in technology for managing their complex operational workflows. Truck drivers are mandated to use electronic logging devices (ELDs) to track their location and hours spent driving throughout the day. Supply chain departments within retail organizations have long used transportation management systems (TMSs) responsible for procuring and coordinating ocean, air, road, and rail carriers to move their goods to a desired destination. Established titans, like BlueYonder or JB Hunt provide an adequate solution for technological coordination, and the massive success of a variety of heavily-funded startups, most notably Convoy, Flexport, and Shipwell, has kicked the industry's technological transformation into gear. As VC investment has accelerated within logistics, software solutions have flourished to manage every one of its many niches. Examples of this are PortPro for drayage (transportation from container ship loading docks) or Lineage Logistics for cold chain management (the process of transporting food and medicine, which must be refrigerated throughout the entirety of their transit). The logistics industry is currently undergoing a technological renaissance, in which every other week a new cutting edge start-up spawns to digitize an arduous manual process.

Despite the significant efficiency gains incurred by this widespread technological transformation, we have quite a ways to go before atoms are as easy to move as bits. It is undeniable that, in recent years, the logistics industry has seen significant local optimizations resulting from automated workflows and software proliferation. Digital freight brokers like Coyote Logistics and Loadsmart, which primarily use software connect shippers with carriers, now offer platforms for which customers can easily request goods to be shipped at a specific rate with an online portal, rather than through over-the-phone negotiation. This phenomena has risen in parallel to an explosion of products providing live tracking and visibility for intermodal shipments, such as Project44 and FourKites. While these technologies have incurred productivity improvements for logistics operators, they fall short of completely abstracting away all manual components of key global logistics workflows. A shipment booking process over the internet is still a shipment booking process, requiring extensive communication between two humans. A visibility solution that provides an operator with the ability to make data-driven decisions, still requires significant input from a human operator.
Software-as-a-service solutions automating individual processes in supply chain management are often restricted in their power by a narrow scope of available API integrations. Without inter-operability, these software solutions remain siloed within the workflows of individual organizations so key logistics processes still require manual data transfers, human decision-making, and live communication for successful completion. The promise of logistics technology mass adoption: fully harmonized port operations that seamlessly organize the thousands of containers passing through every day, endless capacity of trucks, planes, and boats always ready to respond immediately to demand fluctuations, moving atoms as easily as we move bits, only becomes tenable once this hurdle of inter-operability is finally cleared.

Where We're Going

While the current iteration of logistics technology is primarily categorized by siloed solutions specific to individual workflows, the proliferation of software in the industry provides a crucial foundation for the lofty goal of moving atoms as easily as we move bits. Any physical process represented digitally with software can inter-operate with other software so increasingly, every transaction, communication, and hand off surrounding the movement of goods can be read universally with data integrations. End-to-end shipment visibility is currently used primarily in dashboards and reporting, but also enables complex software solutions to fully automate the actions previously taken by humans with carrier location tracking data. Recent offerings by freight brokers enable shippers to seamlessly book loads via an online form or even an API request, enabling freight forwarders, to fully automate carrier procurement at every leg of a shipment’s journey. Many recent VC-funded exploits in logistics technology focus primarily on enabling inter-operability: Kargo builds sensors into loading docks, enabling the automated visibility of shipment pick up and delivery at warehouses and distribution centers and Vector provides software enabling truck drivers to confirm shipment completion without requiring the transfer of the paper documents previously leveraged to complete such transactions.

The downstream impact of the mass investment in workflow digitization will entirely reinvent the procurement of logistics services in the coming decade. To start, initial improvements in inter-operability across the industry has vastly improved the dynamism of freight marketplaces in a variety of modes, particularly over-the-road trucking. While there’s still a long way to go, as evidenced by bottlenecks at ports in recent months, it is becoming significantly easier to hire carriers to haul any commodity that the heart desires. A decade ago, truck drivers and the companies that employed them relied primarily on phone calls to manage business with customers that wish to move goods. Today, every truck driver in America can broadcast their location to anyone who may need their services at the push of a button. If they’d like to be more proactive, they can use load boards to search the expanse of supply chain demand for a high paying job that matches their preferences. A large reason that atoms are so much harder to move than bits, is the immensely sparse communication network between the millions of operators which comprise global supply chains. For a long time, the industry’s endemic software fragmentation made procurement, or the process of contracting of freight services, nearly impossible to complete dynamically. Big-box distributors and e-commerce giants often lack the network to solicit truck drivers precisely when their services are needed the most, entrenching delays and shortages as a common response to unexpected supply shocks. In the coming decade, it will be easier for these drivers, their vehicles, and even their trailers, to communicate with shippers and their transportation management systems, so delays inhibited by shoddy communication will occur less and less frequently.

Some of the more exciting implications of continual interoperability improvements are those regarding improvements to logistics infrastructure over the coming decade. It’s no secret that humanity’s supply chain machine is far from well-oiled. The common culprit of fragmentation inhibits the ability of private organizations to think globally beyond their particular region or specialty. Despite often moving the same goods, and even using similar equipment, cold chain carriers rarely optimize their planning around rail networks, and ocean carriers almost never consider last-mile demand. The limited strategic scope of logisticians within large companies further increases supply chain slack. To repeat the refrain, for a long time, logistics has been interconnected but not inter-operable. As communication barriers fall between the thousands of counter parties which comprise the global logistics ecosystem, it becomes easier to integrate a variety of modular components that work in synchrony to increase productive capacity. Such integrations can serve as foundational infrastructure upon which actors in the logistics ecosystem can expand their scope.

An example of a company that has taken this newfound opportunity to invest in logistics infrastructure is Baton, which has built a network of drop-yards (large lots for parking trucks and trailers) outside of major cities, minimizing the transportation costs to complete deliveries in urban centers. Leveraging advancements in visibility and dynamic procurement, Baton completes shipments for its customers by contracting a single truckload carrier to complete a delivery from the shipment’s origin to one of its drop-yards, and then contracts another truckload carrier to complete the shipment’s journey into a warehouse in a destination city. Enabling shippers to leverage this disjointed transportation strategy minimizes the probability that a truck driver delivering their goods will need to wait hours on an urban freeway, as the second journey that Baton procures is completed when traffic is minimal. Baton coordinates this global optimization through API integrations with transportation management systems for both truckload carriers and companies looking to procure truckload freight. Baton, and similar infrastructure ventures in logistics technology, such as Outrider and Dray Alliance, provide a fascinating glimpse into the potential of interoperable logistics technology to revolutionize key components that are often taken for granted in contemporary logistics systems. If the industry is ever able to approach moving atoms as easily as we can move bits, it will be these massive improvements to fundamental logistics processes that get us there.

Closing Thoughts

Technology trends in the logistics industry will mark the coming decade as a renaissance in the business of moving goods. In this piece, I tried to dig deeper into the potential of logistics technology than most mainstream industry coverage, but in all honesty I feel as though I've only scratched the surface. As technology solutions for aggregation accelerate inter-operability in logistics software, individual shipments, the atomic unit of the industry, can be used as building blocks for highly efficient product offerings. Inter-operability allows freight brokerages to batch shipments from separate carriers and minimize the miles driven by a truck driver without transporting goods in their trailer. It allows last mile delivery solutions to batch shipments going to different addresses in a sufficiently small radius. Perhaps most importantly, it will be crucial for effective and automatic communication between automated software for matching loads to truck drivers and automated software for hauling loads with a truck, even without a driver.

I have yet to even mention the implications of billions entering the global middle class within the coming years, and the titans of emerging markets: Jumia, Rappi, and Shopee that are laying the groundwork to satisfy the massive wave of expected demand. As more consumers demand more stuff, sooner, faster, better, and cheaper, the logistics industry will be forced to bend to their will. The previous century logistics advancement has been characterized by increasingly intricate process alterations aiming to siphon every last drop of unused capacity into productive input. The coming century should be more of the same, continual re-imaginations of contemporary processes, progressing at an exponentially faster rate.

I'd like to thank the day one's for helping turn my mad ramblings into something coherent, and maybe even halfway publishable. I also want to implore any of my lovely readers to reach out to me on twitter @aquariusacquah with any feedback and thoughts. If the prospect of working on moving atoms as easily as bits is something that excites you, I'd love to chat and dive deeper. Subscribe to my new Substack to read more meandering self-actualizations and pop-culture poisoned analyses of technology in various industries, I’ll be writing more on how companies can achieve interoperability in the logistics technology ecosystem, leverage autonomous vehicles, drone delivery, or platform aggregation. My next piece should be out at some point in the next decade, so stay tuned.