5 Secrets to Product Velocity as You Scale with Drata’s VP Product

Product velocity sounds simple until your startup starts growing. In the early days, five people can argue around one table, ship a feature by Friday, and call it “strategy” with only mild exaggeration. But once the company scales, the table gets bigger, the roadmap gets heavier, and every decision suddenly comes with a guest list: product, engineering, sales, customer success, security, finance, legal, leadership, customers, prospects, partners, and someone named Chad who “just has one quick thought.”

That is why the product lessons from Drata’s product leadership are so useful. Drata, a fast-growing security and compliance automation company, scaled in a demanding market where customers care about speed, trust, accuracy, and audit readiness. In a SaaStr session featuring Drata’s VP of Product Brian Elmi and Director of Product Management Dana Mauger, the team shared a practical framework for maintaining product velocity while scaling. The ideas are refreshingly direct: ship quickly, learn faster, stay close to customers, prioritize without flinching, balance vision with execution, and remember that great product work is never “just product.”

This article breaks down those five secrets and expands them into practical lessons for SaaS founders, product managers, product operations teams, and growing companies that want to move faster without accidentally turning their roadmap into a haunted house.

What Product Velocity Really Means

Product velocity is not simply “shipping more stuff.” Any team can ship more buttons, toggles, dashboards, and dropdown menus if quality is optional and customer value is treated like decorative parsley. Real product velocity means delivering meaningful customer outcomes faster, learning from actual usage, and improving the product without creating chaos across the business.

For scaling SaaS companies, product velocity sits at the intersection of three forces: customer insight, technical execution, and organizational alignment. When those three work together, teams move quickly and confidently. When they do not, product development becomes a very expensive group chat.

Drata’s story is especially relevant because compliance automation is not a casual product category. Customers expect reliability, security, integrations, framework coverage, evidence collection, risk visibility, and clear workflows. In other words, the product cannot merely be fast. It must be fast and trustworthy. That tension makes Drata’s approach valuable for any company trying to scale product development responsibly.

Secret 1: Ship Fast, Then Iterate Even Faster

One of Drata’s most memorable principles is the idea of shipping roughly 60% of the use case quickly rather than waiting until the team believes it has built the perfect 90% version. At first, this may sound dangerous. After all, nobody wants a half-baked product, unless we are talking about cookies, in which case some people absolutely do.

But the point is not to ship broken work. The point is to avoid hiding in research, assumptions, and internal debate for so long that the market moves on without you. The final 30% of imagined perfection often takes a disproportionate amount of time, and much of it may be based on guesses. Once customers use the product, those guesses meet reality. Reality is blunt, occasionally rude, and usually more useful than another internal planning meeting.

Why the 60% Mindset Works

Shipping early gives product teams something precious: real behavioral data. Customers may say they want one thing, use another thing, ignore a third thing, and complain about a fourth thing that nobody even considered. That is not a failure of customer research; it is the normal messiness of product discovery.

By releasing a focused version of a feature, teams can answer important questions faster: Are customers using it? Which segments care most? Does it solve the intended problem? What breaks in the workflow? What should be improved first? Which requests are true needs, and which are “wouldn’t it be nice if this also made coffee” suggestions?

The lesson for scaling companies is clear: do not confuse polish with progress. A product team should define the minimum lovable version, not the minimum careless version. Ship something that is useful, safe, and aligned with the customer problem. Then use real feedback to decide what deserves more investment.

Secret 2: Be Competitor Aware, But Customer Focused

Every product team watches competitors. That is normal. It is also healthy. Competitors can reveal market direction, pricing patterns, messaging trends, and capability gaps. But there is a big difference between being competitor aware and being competitor obsessed.

Competitor obsession turns your roadmap into a reaction machine. A rival launches a dashboard, so you launch a dashboard. A rival announces an AI feature, so you announce an AI feature. A rival changes its pricing page, so suddenly six people are in a meeting debating whether your pricing page needs a “modern refresh.” Congratulations, your strategy is now being run by someone else’s marketing calendar.

Drata’s product philosophy emphasizes customer obsession instead. That means the strongest product signals come from people actually using the platform, evaluating it, renewing it, expanding it, or struggling with a workflow that the product can improve.

Turn Customer Feedback Into a Product Engine

Customer focus does not mean saying yes to every request. It means building a disciplined system for collecting, tagging, evaluating, and acting on feedback. Sales conversations, support tickets, customer success calls, onboarding notes, usage analytics, churn reasons, expansion opportunities, and advisory boards all create signals. The hard part is separating signal from noise.

A useful product feedback system asks questions such as:

• How many customers have this problem?
• Which customer segments are affected?
• Is the problem blocking adoption, retention, expansion, or trust?
• Does solving it align with the product strategy?
• Can it be solved with a small improvement, or does it require a larger platform investment?

As companies scale, this feedback loop becomes a competitive advantage. The best teams do not merely collect customer feedback; they operationalize it. They create a living system where product, sales, engineering, customer success, marketing, and leadership can understand what customers need and why it matters.

Secret 3: Practice Ruthless Prioritization

Prioritization is where product managers earn their emotional support snacks. Everyone wants something. Enterprise customers want advanced controls. Sales wants deal-closing features. Customer success wants adoption improvements. Engineering wants technical debt addressed. Leadership wants strategic bets. Marketing wants something shiny to announce. The roadmap, poor thing, sits in the middle trying to breathe.

Drata’s lesson is that product velocity requires ruthless prioritization. Not rude prioritization. Not random prioritization. Ruthless prioritization means being honest about trade-offs and brave enough to say “not now” when a request does not serve the highest-value goal.

Why Saying No Protects Speed

Every yes consumes capacity. It creates design work, engineering work, QA work, documentation, enablement, release coordination, support readiness, and future maintenance. A small feature is rarely as small as it looks when it first arrives wearing a tiny little hat.

Strong prioritization helps teams protect their focus. Frameworks such as RICE, value-versus-effort, cost of delay, opportunity scoring, and customer impact scoring can help, but frameworks are only tools. The deeper discipline is strategic clarity. A team must know which customer problems matter most, which business outcomes matter now, and which initiatives support the long-term product vision.

A practical prioritization habit is to divide work into three buckets: strategic bets, customer-critical improvements, and operational fixes. Strategic bets move the company toward its future vision. Customer-critical improvements improve adoption, retention, or satisfaction. Operational fixes reduce friction, risk, or technical drag. If everything is called strategic, nothing is strategic. If everything is urgent, the roadmap has become a smoke alarm.

Secret 4: Balance Vision With Execution

Product leaders need vision. Without vision, a team becomes a ticket factory, shipping disconnected features that do not compound into a stronger platform. But vision alone is not enough. Customers do not pay for a five-year dream sequence. They pay for value today.

Drata’s product lesson is to think big while starting small. The long-term vision gives the team direction; near-term execution creates proof. This balance is especially important in SaaS because customers judge products continuously. They do not wait patiently for the grand masterpiece while tripping over today’s workflow problems.

Build the Skyscraper One Floor at a Time

A helpful way to think about vision and execution is to imagine building a skyscraper. The vision is the architectural plan. Execution is pouring concrete, installing wiring, checking safety, and making sure floor three does not wobble like a folding table at a picnic.

In product terms, the vision might be to build an integrated trust management platform. Execution might begin with automated evidence collection, then cross-framework control mapping, then trust center workflows, then third-party risk visibility, then AI-assisted questionnaire responses. Each step should deliver real customer value, even before the full vision is complete.

This approach gives customers value along the way and gives the product team better information. Each release teaches the team something. Each customer interaction sharpens the roadmap. Each operational challenge reveals where the platform needs stronger foundations.

The mistake many teams make is treating vision as a fixed statue. In reality, product vision should be durable but not frozen. The destination may stay consistent, but the route should adapt as customers, markets, technology, and regulations evolve.

Secret 5: Remember That Product Velocity Is More Than Product

One of Drata’s most important points is that scaling product velocity depends on three pillars: people, process, and product. This matters because many companies try to solve product speed problems by pressuring the product team alone. That is like blaming the chef because the entire restaurant has no electricity.

People: Hire for Trust, Ownership, and Judgment

Fast product teams need strong people. Not just talented people, but people who can make decisions with incomplete information, collaborate across functions, and stay close to customer value. In high-growth environments, ambiguity is not a temporary weather pattern. It is the climate.

Great product hires bring curiosity, judgment, humility, and communication skills. They can say, “I do not know yet, but here is how we will learn.” They can disagree without turning a roadmap review into a courtroom drama. They can connect technical trade-offs to business outcomes and customer needs.

Process: Build Feedback Loops Before the Company Gets Too Big

Process has a branding problem. Many people hear “process” and imagine a sad spreadsheet wearing a necktie. But good process is not bureaucracy. Good process is how a scaling team keeps moving without stepping on its own shoelaces.

For product velocity, the most important processes include intake, prioritization, discovery, roadmap planning, release readiness, customer feedback, and post-launch measurement. These systems do not need to be heavy. In fact, the best ones are usually lightweight, visible, and repeatable.

At scale, product teams need a clear loop from prospect feedback to sales, from sales to product, from customer success to product, from product to engineering, from engineering to release, and from release back to the customer. When that loop is healthy, the company learns faster. When it is broken, teams make decisions based on anecdotes, volume, politics, or whoever spoke most confidently in the meeting.

Product: Solve the Right Problem, Not Every Problem

The final pillar is the product itself. A fast team building the wrong thing is not a high-velocity team. It is just lost at impressive speed.

Product velocity should always be tied to customer outcomes. For Drata, that may mean helping companies automate compliance work, maintain audit readiness, manage risk, share trust information, or reduce manual evidence collection. For another SaaS company, it might mean improving onboarding, reducing time to value, increasing workflow automation, or helping users make better decisions.

The principle is universal: speed only matters when it moves customers toward a valuable outcome.

How Scaling Teams Can Apply Drata’s Product Velocity Lessons

The five secrets are powerful because they are practical. They do not require a magic framework, a 97-slide transformation deck, or a consultant who says “synergy” more than legally necessary. They require discipline.

Create a Velocity Scorecard

Scaling teams should measure product velocity beyond story points or release counts. Better metrics include adoption rate, activation improvement, customer satisfaction, support ticket reduction, expansion influence, retention impact, release cycle time, experiment learning rate, and percentage of roadmap tied to strategic objectives.

The goal is to understand whether the team is moving faster toward value, not simply moving faster in general.

Separate Discovery From Delivery

Many teams slow down because discovery and delivery become tangled. Discovery asks, “What problem should we solve?” Delivery asks, “How do we build the solution well?” Both are necessary, but they require different rhythms.

A mature product organization keeps discovery continuous. Product managers, designers, and researchers should always be learning from customers, while engineering teams deliver validated work. This reduces last-minute surprises and helps the roadmap stay flexible without becoming chaotic.

Build Small Teams With Clear Ownership

Large cross-functional groups often feel inclusive, but they can also slow decisions. Product velocity improves when teams have clear ownership, clear goals, and clear decision rights. A small team with strong context can move faster than a large committee with perfect attendance.

This does not mean teams should operate in silos. It means collaboration should be structured. Alignment should happen around goals, customer problems, dependencies, and metrics. Execution should remain focused.

Common Product Velocity Mistakes to Avoid

Mistake 1: Shipping Fast Without Learning

Fast shipping is only useful if it creates learning. If a team releases features but never measures usage, gathers feedback, or reviews outcomes, it is not iterating. It is decorating the product at high speed.

Mistake 2: Letting Enterprise Deals Hijack the Roadmap

Enterprise customers can provide valuable insight, but one large deal should not automatically rewrite the product strategy. Teams need a clear way to evaluate whether a requested feature supports the broader market or creates custom complexity that will slow everyone down later.

Mistake 3: Treating Technical Debt as a Future Problem

Technical debt is like laundry. Ignore it long enough and eventually it becomes furniture. Scaling teams need to reserve capacity for platform quality, performance, security, and maintainability. Otherwise, velocity today becomes gridlock tomorrow.

Mistake 4: Confusing Internal Excitement With Customer Value

A feature can sound amazing in a strategy meeting and still fail in the wild. Customers are the final judge. Product teams should test assumptions early, validate demand, and avoid falling in love with ideas before the customer does.

Practical Experiences: What Product Velocity Feels Like in the Real World

In real product teams, velocity rarely feels glamorous. It often looks like a product manager rewriting a spec after three customer calls reveal that the original assumption was only half-right. It looks like an engineer pointing out that the “simple change” requires rethinking permissions. It looks like a customer success manager explaining that users are confused not because the feature is weak, but because onboarding skips the moment where the feature would make sense. In other words, product velocity is not a sprint through a sunny meadow. It is more like building the bicycle while riding it, except the bicycle has enterprise security requirements and someone from sales is asking whether it can also fly.

One practical experience many scaling teams share is the pain of feedback overload. Early on, every customer request feels precious because there are only a few customers. Later, the company has hundreds or thousands of signals coming from calls, tickets, Slack channels, CRM notes, surveys, win-loss reviews, and executive escalations. Without a system, the loudest request wins. With a system, patterns emerge. A feature requested by three strategic accounts, tied to onboarding friction, and supported by usage data deserves a different conversation than a one-off request from a prospect who may never buy.

Another common experience is the tension between roadmap confidence and market change. A team may enter the quarter with a beautifully planned roadmap, complete with color-coded themes and optimistic timelines. Then a new regulation appears, a competitor launches something interesting, a major customer surfaces a critical gap, or AI changes what customers expect from the workflow. Strong teams do not panic. They revisit priorities, protect the strategy, and adjust execution. Weak teams either ignore the new information or throw the entire roadmap into a blender.

Product velocity also depends heavily on trust between product and engineering. When trust is low, every estimate becomes a negotiation, every scope cut feels political, and every delay turns into a detective story. When trust is high, teams can make smart trade-offs quickly. Product can explain the customer impact. Engineering can explain technical constraints. Design can protect usability. Together, they can decide what belongs in the first release and what should wait.

The best scaling teams also learn to celebrate iteration, not just launch day. Launches are exciting, of course. There may be a company announcement, a customer email, maybe even a GIF in Slack that deserves its own performance review. But the real product work begins after launch. Are customers adopting it? Are they succeeding? Are they confused? Are they asking for the next logical capability? Did the feature reduce friction or merely relocate it? Teams that treat launch as the finish line lose velocity. Teams that treat launch as the start of learning compound their speed over time.

Finally, product velocity becomes easier when leaders create focus. Teams do not move faster because leaders shout “move faster” with executive enthusiasm. They move faster when leaders reduce ambiguity, clarify priorities, remove blockers, and protect teams from constant context switching. Focus is a gift. In a scaling company, it may be the most underrated gift of all.

Conclusion: Product Velocity Is a System, Not a Slogan

The five secrets to product velocity from Drata’s product leadership are powerful because they are simple enough to remember and hard enough to require real discipline. Ship fast and iterate faster. Watch competitors, but listen harder to customers. Prioritize ruthlessly. Balance long-term vision with near-term execution. Build the right people, process, and product foundation before scale turns small cracks into structural problems.

For SaaS companies, product velocity is not about reckless speed. It is about learning velocity, decision velocity, customer value velocity, and organizational alignment. The teams that win are not always the teams with the longest roadmaps. They are the teams that know which problems matter, move quickly toward useful solutions, and keep improving after the first release.

Note: This article is written as original, publication-ready content based on publicly available information about Drata’s product velocity principles and widely recognized SaaS product management practices.