WalnutAI Q4 Roadmap: 3 Features, 1 Non-Decision

Three features shipping in Q4. One feature we decided not to build. The customer conversations behind each choice.

How we plan

We don’t have a roadmap committee. We have customer conversations. Every quarter, we look at what our customers actually asked for, what we heard repeatedly, and what we think we can do well by the end of the quarter. This is that conversation, public.

Shipping in Q4

1. Real-time requirement sync (Jira and Azure DevOps) The problem: A QA lead uploads a spec in March. Devs write tests against it. In July, the PM updates the spec in Jira (adds a new acceptance criterion). The tests don’t know that changed. They’re validating against a spec that no longer exists.
   
   Customer story: A fintech team had requirements drift silently for weeks. Gap analysis caught it two days before release. They rebuilt test coverage in a panic. They told us: “if our tests had known the requirement changed, we would’ve caught this in standup.” Real-time sync works like this: when someone updates a requirement in Jira or ADO, WalnutAI’s test coverage immediately recalculates. If a test no longer covers the new acceptance criterion, it flags it. You see it in your next CI run, not two days before launch. Shipping mid-October. Early access available now.

2. Team quality dashboards (per-sprint quality scores for leadership) The problem: A QA director runs tests. Pass rate is 94%. What does that mean to the CEO? Is the release ready? Is this sprint better than last sprint? The director doesn’t have a way to answer.
   
   Customer story: A SaaS PM asked her QA director every standup: “how many tests failed this week?” The QA director would say “6 test failures.” The PM couldn’t tell if that was good or bad. Six failures on a suite of 40 is different from six failures on a suite of 2000. The PM wanted a scorecard. Team quality dashboards give you: per-sprint quality scoring (weighted by test importance), trend charts (is quality improving or degrading?), release readiness indicator, and a leadership report you can share in board meetings. No jargon. Just: “this sprint is 87% release-ready.” Shipping end of October. Open beta for existing customers now.

3. Intelligence Hub for audio (meeting recordings → test cases) The problem: A product team has a spec meeting. The PM talks through requirements. That meeting happens, nobody writes them down in Confluence, and three weeks later the devs build what they remember. Intelligence Hub works off documents. What about the intelligence in unstructured conversations?
   Customer story: An early-stage startup had all their requirements in Slack threads and recorded Zoom calls. Their only “official” spec was whatever the PM could remember. They wanted to upload meeting recordings and get test cases. We said “we’re not there yet.” They said “can we beta it?” We’re making them right. Audio Intelligence Hub: record a meeting (or upload a transcript), and WalnutAI extracts the requirements and generates test cases the same way it does for documents. You get a searchable, testable artifact from every spec meeting. Shipping November. Private beta with 10 customers. Apply at the end of this post if you want in.
   
   Not shipping in Q4: Automated test execution

   This one is interesting because we get asked for it frequently, and because we decided not to build it. Here’s why.

The ask: “generate tests and run them for me. I don’t want to think about execution.”

We get it. Sounds great. But it’s a different product than what we’re building.

Why we’re not doing it: Test execution is a solved problem. TestRail, Xray, Testrail, and others handle it well. Your CI/CD pipeline handles it. Adding “and run the tests” to WalnutAI would mean we’re competing on features where others already win, instead of staying focused on what we’re best at: test generation, traceability, and gap analysis.

More importantly: if we build test execution and it breaks, we now own your release pipeline. That’s a support and reliability commitment we’re not ready to make. We care too much about your success to ship that half-done.

What we’re doing instead: We’re building better integration with your existing test runners. You generate tests in WalnutAI, export them to your tool of choice, and run them the way you already do. We stay focused on generation and judgment. You keep control of execution.

If that doesn’t solve your problem, tell us. We’re listening. But if you’re looking for a one-stop test automation platform, there are better options than us, and that’s okay.

How we got here: the decision process

Every feature request gets sorted into a decision tree:

• Does a customer need it? (Not “is it nice to have,” but “would it solve a real problem they’re facing?”)

• Can we do it well by quarter-end? (Partial features ship broken. We don’t.)

• Is it a natural extension of what we’re already good at? (Real-time sync + test generation = yes. Test execution + traceability = no.)

• If we build it, can we support it reliably? (If not, we don’t.)

Real-time sync, quality dashboards, and audio Intelligence Hub checked all four boxes. Automated test execution failed box 2 (we’d need another quarter) and box 3 (it’s not our core thing).

What happens next

These ship in October and November. We’re taking early access sign-ups now. No charge for early access; if you break things, you help us fix them.

We’ll spend Q1 listening to how teams use the new features and what gaps are still there. That’s how we plan 2027.

Open question to the community

What did we get wrong? What’s coming in Q4 that you think we should reconsider? What did we leave out that you actually need?

Apply for early access to Q4 feature . schedule time with the team to see what’s coming.