Rajiv Gupta is a Principal Product Leader at AWS driving cross-functional business strategy for cloud infrastructure and AI storage.getty​For many successful products, the clearest signals of unmet needs do not show up in customer interviews or roadmap reviews first. They show up in manual workflows that everyone has learned to tolerate.A customer requires something. Sales escalates. Product gets pulled in. Engineering confirms feasibility. Finance reviews. Legal weighs in. Someone creates a tracker, someone else creates a template and after messy coordination, the customer gets what they need. The first time, it feels like a fire drill. The second time, it feels like a process. Over time, it's quietly accepted as the way the business operates. At that point, the product question is whether the workflow is exposing a product capability that has not been built yet.A workflow handles a specific situation. It works when volume is low or human judgment is required. A product capability is different. It turns the repeatable parts of that workflow, not necessarily the entire workflow, into a product. It defines inputs, decision rules, customer experience, human versus machine touchpoints, outputs and feedback loops that can work across many customers or partners.When Manual Is Still The Right AnswerRepeated manual work can mean different things. Sometimes it is just a process that needs simplification. Sometimes it involves high-judgment decisions that still require a human. But sometimes it is a demand showing up in a form that only a product can support at scale.Customer onboarding at a startup is a good example of work that should often remain manual for a while. When a product is still young, high-touch onboarding helps the team understand where customers get stuck, what support they need, what data they need and what repeats. Building a self-service onboarding product too early can lock in the wrong process, waste learning opportunities and create rework.A process should remain manual until it has enough mass to teach the team what should be standardized. Early manual work can be a valuable discovery process. It exposes customer variation, edge cases, judgment points and steps that repeat often enough to become product infrastructure.When The Signal ChangesThe signal changes when the same pattern keeps appearing across customers, partners, geographies or sales motions. If multiple customers ask for the same workaround, it may point to a product gap. If multiple employees make similar judgment calls, there may be decision logic to standardize. If the business cannot support more volume without adding headcount, the operating model may be ahead of the product model.These are often the highest-return opportunities, but they're also the hardest to solve. If a workflow is still manual despite showing up repeatedly across a large customer base, there is usually a reason. The process may cut across teams, systems, incentives, owners and customer segments. Automating it may require changes to product architecture, commercial terms, approvals, data flows or operating models, or alignment across team boundaries. That complexity is why the workflow survived manually for so long. It is also why solving it well can create outsized leverage.Productizing What Has Actually StandardizedThe product manager’s job is not to automate everything. Most workflows contain both repeatable and judgment-based components. Some steps are stable: collecting inputs, checking eligibility, routing approvals, generating documents, notifying stakeholders or triggering provisioning. Other steps require human judgment because the customer situation is unusual, the risk is unclear or the commercial structure is not standard. A good product separates these parts. It standardizes what is stable and preserves judgment where needed.Once the product manager identifies the steps that have standardized through repeated use, their product design should mirror those steps closely enough that users recognize it. Product managers should not replace manual work with whatever workflow looks cleanest on a whiteboard. A manager may see a messy process and design what feels like the ideal version of a product. But if that version does not match how customers, partners or internal teams make decisions, the product often creates new friction.Someone once told me, “People do not adopt tools that make them relearn work they already know how to do.” That may sound obvious, but it is one of the most important rules in workflow automation. Many ideal workflows live and die in spreadsheets because they solve the product manager's version of the problem, not the user’s.Take expense management as an example. Employees were already submitting receipts, managers were approving them and finance was checking policies. Products like Expensify and Concur did not ask users to learn a new mental model. They moved the familiar workflow into software, making it faster, clearer and easier to audit.Compliance automation is another example. Before products like Vanta and Drata, companies often collected audit evidence through spreadsheets, screenshots, emails and repeated requests to engineering and security teams. The workflow stayed manual for so long not because people enjoyed the pain, but because automating it was complex. The workflow spanned multiple systems, teams, risk owners and external auditors. Solving it required more than a better checklist; it required turning evidence collection and control monitoring into product infrastructure.Putting It All TogetherThe same pattern shows up in other areas. Procurement becomes marketplace infrastructure. Financing becomes embedded payment infrastructure. Customer onboarding becomes activation flows, templates, telemetry and success signals.Once customers experience internal coordination as a delay, the workflow has become part of the product experience.That is where the product manager’s role becomes important. The product manager has to translate a messy operational reality into a scalable product model. That means understanding what is repeated, what is variable, where risk enters, where customers feel delay, what data is missing and what would break if volume increased significantly.As product and engineering teams become faster at building, I've found that the bottleneck increasingly shifts from execution to direction. The question is not only whether a team can turn a workflow into software. The question is whether doing so creates a durable product capability.A workflow may help the business get through today. A product capability is what allows the business to scale tomorrow.​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?