Why Series B Is the Right Time to Invest in a Requirements Tool

Written by Simon Bennett | Oct 20, 2026, 5:36:00 PM

WATCHTOWER BRIEF · REQUIREMENTS & SAFETY · GO-TO-MARKET

AiT × JAMA SOFTWARE · A VIEW FROM THE WATCHTOWER

Every silicon startup keeps its first requirements in a spreadsheet or a Jira project. At seed, that is the right call. By Series B it has quietly become technical debt, and the round that just closed is the cheapest moment you will ever have to pay it down.

IN BRIEF

Excel and Jira are the right start. At seed, a small team sitting together can hold the spec in its head. Speed beats process.

Series B changes the math. The team grows and spreads out, the first customers bring their own requirements, and one chip becomes a roadmap.

Requirements debt compounds: lost traceability, version drift, changes nobody can assess, and customer evidence rebuilt by hand before every review.

Waiting makes it more expensive. Every new spec, engineer and derivative adds to the migration you will eventually have to do.

The fix is a requirements foundation, not more process: live traceability that works alongside the tools engineers already use.

The weeks after a Series B closes are some of the busiest in a startup's life. There is a hiring plan to execute, a tapeout date that just became real, and a lead customer who now expects the company to behave like a supplier rather than a science project. Nobody in that room is asking which tool holds the requirements.

They should be. I have watched this from both sides: selling into silicon teams at Synopsys, and sourcing external IP at Intel. The startups that struggle at their first production milestone rarely struggle because the architecture was wrong. More often, nobody can say with confidence which version of the spec the RTL, the verification plan and the customer's datasheet were each built against.

Why do semiconductor startups start their requirements in Excel and Jira?

Because at seed, it is the right decision. The founding team is small, usually in one room, and the product definition lives in the architect's head and a few slides. A spreadsheet is free, everyone already knows it, and it can be reshaped in an afternoon when the architecture pivots. Jira is already running for the software team, so a requirements project next to the sprint board feels natural.

Nothing about that is careless. Early-stage companies are optimizing for learning speed, and heavyweight process would slow them down. The problem is not the starting point. The problem is that the starting point never gets revisited.

What changes for a chip company at Series B?

Series B is usually the round that turns a working design into a product. The money is there to scale the team, tape out a production part and win design-ins. Each of those changes what the requirements have to do.

What Series B adds to the requirements load
MORE PEOPLE, MORE PLACES	The team grows past the point where everyone hears every decision, often across sites and time zones. The spec has to work for engineers who were not in the room when it was written.
CUSTOMER REQUIREMENTS	Lead customers send their own requirements, compliance expectations and change requests. Those have to be captured, traced and answered, not lost in email threads.
PARTNERS AND IP	Third-party IP, foundry and packaging partners each bring requirements and constraints that flow into the design and must be tracked across company boundaries.
ONE CHIP BECOMES A ROADMAP	Derivatives and next-generation parts reuse much of the first spec. Reuse only works if you know exactly what the original requirements were and how they were verified.
EVIDENCE	Customers, auditors and, later, Series C diligence will ask you to show how requirements were verified. “Trust us” stops being an answer.

What is requirements technical debt?

Software engineers know technical debt as the cost of a shortcut that has to be repaid later, with interest. Requirements debt works the same way. Each requirement kept in a cell, a slide or a ticket comment is a small loan. Individually they are harmless. Together, at scale, they show up as a recognizable set of symptoms.

NO TRACE	Nobody can show, without a week of archaeology, which verification tests cover which requirements, or which requirements a given block implements.
VERSION DRIFT	Three copies of the spec circulate: the one in the shared drive, the one attached to the customer email and the one the verification lead downloaded last quarter.
BLIND CHANGE	A customer asks for a change and nobody can say quickly what it touches: which blocks, which tests, which firmware, which other customers.
EVIDENCE BY HAND	Before every design review or customer audit, engineers rebuild the traceability story manually from spreadsheets and ticket exports.
TRIBAL KNOWLEDGE	The reasoning behind a requirement lives with the engineer who wrote it. When that engineer moves on, the reasoning goes too.

A spreadsheet records what you decided. It cannot tell you what a change will break.

Why don't Excel and Jira scale for silicon requirements?

Excel has no relationships. A requirement in row 412 has no live link to the test that verifies it, the block that implements it or the customer request that created it. Teams simulate those links with extra columns and naming conventions, and the simulation breaks the first time someone sorts the sheet or saves a copy.

Jira is built for work, not for requirements. A ticket is meant to be opened, worked and closed. A requirement has to live for the life of the product and every derivative after it. Jira links are ad hoc, baselines are hard to establish, and there is no natural way to ask “which requirements are not yet covered by a test?” Jira is excellent at what it was designed for. Requirements management is not that.

We made a similar argument about IP management in Silicon IP Operations: Your PLM Can't Do It, and Neither Can Jira. The pattern repeats: general-purpose tools stretch impressively far, and then fail exactly when the stakes rise.

Why is Series B the right time, rather than later?

Because every alternative moment is worse.

Earlier is premature. At seed the product definition is still moving too fast, and the team is small enough that informal coordination works.

Later is expensive. The cost of migrating requirements grows with every spec written, every engineer hired and every derivative started. A company that waits until Series C is migrating several products' worth of tangled history, usually under the pressure of a customer audit or a production problem.

Series B is the window. The company has enough real requirements to justify a proper foundation, the capital to fund it, and a hiring wave about to arrive. The habits new engineers learn in their first month become the company's process. Put the foundation in before they arrive, and it becomes simply how the company works.

There is a customer-facing reason too. Lead customers judge a startup partly on whether it can answer their questions about requirements, changes and verification quickly and credibly. That is a competitive advantage at exactly the stage when design-ins are won or lost. We explored why that thread matters across company boundaries in Tracking Requirements Across Company Boundaries.

What should a Series B silicon team look for in a requirements tool?

A short checklist
LIVE TRACEABILITY	Requirements linked to design, verification and test as they change, not reconstructed in a spreadsheet before each review.
WORKS WITH YOUR TOOLS	It should connect to the tools engineers already use, including Jira, rather than asking anyone to abandon them.
BASELINES AND REVIEWS	The ability to freeze, compare and formally review a version of the spec, and to show a customer exactly what changed between versions.
REUSE	Requirements that can be carried into a derivative product with their history and verification status intact.
REQUIREMENT QUALITY	Help writing clear, testable requirements, increasingly assisted by AI, so ambiguity is caught before it reaches RTL.
LIGHT ADOPTION	Something a growing team can adopt in weeks, without a dedicated tools group.

Where does Jama Connect fit?

Jama Software describes Jama Connect as the AI-native engineering management platform, built on the requirements foundation engineers trust. Jama Connect is built around Live Traceability across best-of-breed engineering tools, so requirements stay connected to the work that implements and verifies them, rather than living in a separate silo.

For a growing team, two capabilities stand out. Jama Connect Advisor analyzes requirement text and scores it against INCOSE and EARS rules, which is a practical way to raise requirement quality as new engineers start writing specs. And Jama is investing in further AI assistance across the requirements lifecycle, such as flagging high-risk requirements and suggesting test cases, through Jama Labs.

In our EDA 3.0 framework, requirements and intent are Layer 1: the thread every later layer, from architecture through verification and yield, depends on. We argued in What Falls Between the Silos that AI orchestration across the semiconductor lifecycle needs exactly that kind of living requirements thread. A startup that builds it at Series B is ready for that future; one that does not will be rebuilding it later.

Frequently asked questions

What is requirements technical debt?

Requirements technical debt is the accumulated cost of managing requirements in tools that cannot track relationships, versions or verification, such as spreadsheets and general-purpose ticketing systems. It shows up as lost traceability, version drift, slow impact analysis and manual evidence gathering, and it grows as the team and product line grow.

Why is Series B a good time for a semiconductor startup to adopt a requirements management tool?

Series B is when a startup typically scales its team, tapes out a production part and engages lead customers. The company has enough real requirements to justify a proper foundation and the capital to fund it, while the cost of migrating is still far lower than it will be after more products and engineers are added.

Can Jira be used for requirements management?

Jira can hold requirements, and many startups begin there. But Jira is designed for work items that are opened and closed, not for requirements that must persist across a product's life. It lacks natural support for baselines, formal reviews and coverage analysis, which become essential as a silicon program scales.

What is live traceability?

Live traceability means requirements stay continuously linked to the design, verification and test artifacts that implement and prove them, so the relationships update as work changes. It replaces traceability matrices rebuilt by hand before each review.

Do teams have to stop using Jira to adopt a requirements tool?

No. A modern requirements platform should connect to the tools engineers already use, including Jira, so software teams keep their workflow while requirements gain a proper home with traceability and version control.

What is EDA 3.0?

EDA 3.0 is AiT's term for the shift from tool-centric, siloed electronic design automation to an AI-native lifecycle that connects intent and requirements through architecture, firmware, verification and yield, with shared executable models at its core.

AiT represents Jama Software in North America for semiconductor companies. If your company has just closed a Series B and any of this sounds familiar, I would be glad to hear how requirements are handled today, and to set up a conversation with the Jama team. Reach me directly at simon@ai-techsales.com.