Wrightery
How it worksWorkbenchUse casesLibrary
How it worksWorkbenchUse casesLibrary
Wrightery

Vibe working for analysis. Your AI analyst team researches, cross-checks, and drafts from trusted sources. You review the evidence and make the final call.

Product

How it worksWorkbenchUse cases

Company

TeamBook a meeting ↗
© 2026 Wrightery.
v1.2610.260322192c31a7d8
  1. Library
  1. 1Daniel’s Journey to Build a ChatGPT Challenger
  2. 2Chapter 1 — Nine Months
  3. 3Chapter 2 — The Product in the Sales Deck
  4. 4Chapter 3 — What Are We Competing For?
  5. 5Chapter 4 — The CTO in the Code Review
  6. 6Chapter 5 — The Architecture That Grew by Accident
  7. 7Chapter 6 — The First Customer Promise
  1. Library
Chapter 2 of 7·11 min read

Chapter 1 — Nine Months

Chapter 1 — Nine Months
Chapter 1 — Nine Months

“Nine months,” Olivia said.

Daniel looked at the number on the final slide but did not answer immediately.

The boardroom occupied the northwest corner of Aureline Labs’ Vancouver office, high enough to make the harbor look calm. Rain had erased the mountains. On the screen, a blue line rose from the lower left to the upper right beneath a blunt promise: ENTERPRISE LAUNCH — MAY 2027.

Around the table, everyone appeared to be waiting for an estimate. What they actually wanted was permission to believe the company could still win.

Olivia Park stood beside the screen, one hand resting on the back of an empty chair. She had the composure of a founder who had delivered the difficult part of the news before the meeting began. Aureline had fourteen months of runway. The next financing depended on evidence that the company could become more than a respected enterprise-search vendor. The board wanted a credible challenger in the conversational-AI market, a strategic customer in production, and a path to sustainable margins.

All three had to happen before summer.

“Nine months to do what?” Daniel asked.

Evan Brooks, the Chief Revenue Officer, leaned forward. “To launch.”

“Launch a chat interface? Pass a customer’s security review? Support ten thousand users? Or become the product described in the sales deck?”

The room became quiet.

Marcus Hale closed his laptop. “That,” the CTO said, “is why we hired you.”

Daniel had joined Aureline eleven days earlier as Director of R&D. Long enough to learn everyone’s name. Not long enough to know which version of the company’s reality each name represented.

He had seen the prototype. Auralis could hold a natural conversation, search an uploaded collection of documents, and draft a polished report with citations. In the controlled demonstration, it felt almost finished.

He had also watched a forty-eight-page policy document remain in Processing for twenty-three minutes before failing without explanation. He had seen two answers to the same question cite different paragraphs. He had discovered a production service that only one engineer knew how to deploy and a spreadsheet in which model costs were projected as a fixed percentage of subscription revenue, regardless of usage.

None of those facts meant the product would fail. Together they meant the date on the slide was not yet a plan.

Leila Morgan, Aureline’s Chief Product Officer, turned toward him. “The outcome is an enterprise-ready release of Auralis. Collaborative workspaces, governed organizational knowledge, evidence-backed answers, reusable assistants, and controlled actions. The pilot customer should be able to use it for real professional work.”

“How will we know we’ve succeeded?”

“They renew,” Evan said.

“Eventually. What evidence lets us decide they are ready to begin?”

Olivia clicked back one slide. It showed a clean product mockup beneath the phrase Intelligence you can trust, govern, and put to work. On the right were four checkmarks: secure, accurate, scalable, enterprise-ready.

“We know what the market expects,” she said. “We cannot spend a quarter debating definitions while everyone else ships.”

Her impatience was reasonable. Every week brought another model, agent framework, or enterprise assistant. Customers who once tolerated twelve-month software roadmaps now asked what could be demonstrated next Tuesday. A larger competitor could turn Aureline’s entire category into a checkbox between earnings calls.

Daniel uncapped a marker and walked to the whiteboard.

“I’m not asking us to wait for certainty,” he said. “I’m asking which uncertainty we are accepting.”

He wrote four headings.

Business outcome. Customer. Product contract. Evidence.

“If we do not define these, engineering will still make decisions. They’ll just make different ones. Sofia will optimize the experience people can see. Ravi will optimize model capability. Hannah will protect retrieval quality. Noah will protect reliability. Omar will protect the company from risks the rest of us are rewarded for taking. All of them will be right, and the product may still be wrong.”

Marcus smiled faintly. “You have met them.”

“Not enough. But I’ve met this problem.”

Victor Lang, the board member attending by video, spoke for the first time. His face filled the small display at the end of the table. “Daniel, I appreciate precision. I also appreciate companies that survive. Can this team do it in nine months?”

It was the question beneath every other question, and Daniel knew three ways to answer it badly.

He could say yes and purchase alignment with confidence he had not earned. He could say no and turn incomplete knowledge into a verdict. Or he could describe every unknown until caution became indistinguishable from refusal.

He looked at the slide again. “I don’t know yet.”

Evan exhaled through his nose.

“I can tell you what I believe,” Daniel continued. “We have enough talent to build a serious product. We do not yet have one shared definition of the product, a delivery system that produces dependable forecasts, or evidence that the current architecture can satisfy the promise. Nine months is possible. Today it is not a commitment I can defend.”

Victor’s expression did not change. “When can you defend one?”

“Four weeks.”

“A month to produce an estimate?”

“A month to produce a decision system. At the end, you’ll get a target range, the assumptions that determine it, the risks that could move it, and the evidence we’ll use to narrow it. You’ll also get the first things we will stop doing to make the target credible.”

Olivia sat down. “Walk us through the month.”

Daniel drew a line across the board and divided it into four sections.

In the first week, the executive team would choose a market wedge and a named customer outcome. Not “enterprise AI.” Not “a better ChatGPT.” A bounded job performed by a specific professional, with a reason to choose Auralis.

In the second, product and engineering would convert that choice into a product contract: essential workflows, service expectations, security and privacy boundaries, supported scale, and explicit exclusions. The contract would describe what a customer could depend on, not every feature the company hoped to demonstrate.

In the third, the R&D leaders would test the inherited system against that contract. They would map the architecture, ownership, dependencies, quality evidence, operational capability, cost behavior, and work already in progress. Unknowns that mattered would become short experiments rather than arguments.

In the fourth, the leadership team would present three executable options: the smallest credible release, the planned enterprise release, and an accelerated release with its required investment and accepted risk. Each option would include learning milestones and conditions for continuing, narrowing, or stopping.

“And meanwhile?” Evan asked. “Do the teams pause while leadership discovers itself?”

“No. Customer learning continues. Reliability work continues. Any feature that is valuable under all three options continues. Anything that only makes sense under one unchosen strategy has to justify why it cannot wait four weeks.”

“That will feel like a pause,” Evan said.

“Some work should pause.”

The answer landed harder than Daniel intended. Through the glass wall, he noticed Sofia Alvarez, Engineering Manager for Product Experience, looking over from the adjacent meeting room. Her team had been working evenings on a new assistant builder for a conference demo. Daniel did not know whether it was essential, optional, or already promised. That ignorance was precisely the problem, but the people doing the work would experience any correction as a judgment on them.

Leila tapped her pen against her notebook. “I can define the workflow with Claire’s team. They care about evidence-backed policy research and controlled report generation. But I don’t want one design partner to become the entire product strategy.”

“Then the wedge needs two tests,” Daniel said. “A painful outcome for Claire and a repeatable problem in the market. Specific does not have to mean bespoke.”

Marcus reopened his laptop. “The architecture can support it. The original design assumed model portability, retrieval across tenant knowledge, and an agent runtime.”

“Assumed or demonstrated?” Daniel asked.

Marcus’s eyes moved from the laptop to Daniel. It was a small change, but the room felt it.

“Some demonstrated. Some designed.”

“Then we’ll preserve the parts the evidence supports and test the rest.”

Daniel had not meant the sentence as a challenge. Marcus had built the first version of Aureline’s platform and remained the strongest systems engineer in the company. But in Daniel’s first week, three people had given him three different answers to the same question: who held authority over technical execution? Marcus saw himself as guardian of the platform. The engineering managers saw him as an unpredictable reviewer. Olivia saw both men as necessary.

Nine months had already exposed its first dependency, and it was not technical.

Olivia walked to the whiteboard and read the four headings.

“Business outcome. Customer. Product contract. Evidence.” She circled the last word. “I need speed, Daniel. Evidence cannot become the name we give to fear.”

“Agreed. And urgency cannot become the name we give to guessing.”

Victor leaned closer to his camera. “What decision do you need from us today?”

Daniel had expected another demand for a date. The question was better.

“Authorize the nine-month target as a strategic constraint, not yet a delivery commitment. Give the executive team four weeks to define the release and the evidence. During those four weeks, no one makes a new customer commitment without product and R&D review. At the next board session, we bring options, not one optimistic number.”

Evan shook his head. “If every conversation waits for engineering approval, we will miss the market before we finish the plan.”

“Not every conversation. Every commitment. Sell the problem, the direction, and the learning partnership. Do not sell a control, integration, scale level, or date we have not examined.”

“Customers ask for dates.”

“Then we tell them which date is a target, which is a commitment, and what must be true before it changes from one to the other.”

Olivia looked to Leila, then Marcus, then the rain beyond the glass. Daniel could almost see the competing clocks: the runway, the board, the customer, the conference, the engineering work, and the market moving outside all of them.

“Four weeks,” she said. “But I want the first readout in seven days. Not findings. Decisions we can make.”

“You’ll have it.”

“And May stays on the wall.”

“As a target.”

“As the target.”

Daniel nodded. It was close enough to agreement to begin.

The meeting ended with the hurried movement of people who had acquired more work without gaining more time. Evan left first, already dictating a message. Leila photographed the whiteboard. Marcus remained seated until the room had emptied.

“You told the board you don’t know,” he said.

“I do that when I don’t know.”

“It is not a universally admired executive habit.”

“Neither is missing a commitment.”

Marcus stood and put his laptop under his arm. “The prototype is better than you think.”

“I hope so.”

“And the organization is less broken than your four-week diagnosis implies.”

Daniel capped the marker. “I hope that too.”

Marcus stopped at the door. “Nine months is a long time in this market.”

“And a short time in an enterprise.”

After he left, Daniel looked at the whiteboard. The four headings were already drying on its surface. Beneath them, almost as an afterthought, he wrote a fifth.

Authority.

His calendar showed a product review in twelve minutes. A message from Sofia waited at the top of his inbox.

Quick warning before the review: the sales deck contains three things we do not have.

Daniel read it twice.

The nine months had begun.


Director’s Lens

A deadline is a constraint, not a definition

Senior leaders often ask engineering for a date before the organization has agreed on the result. The request is understandable. Funding, customer decisions, competitive windows, contracts, and hiring all depend on time. Refusing to engage until every requirement is known is not leadership.

Neither is attaching false precision to an undefined outcome.

Daniel separates two things that organizations frequently collapse:

  • A strategic target creates urgency and shapes trade-offs.
  • A delivery commitment is a promise supported by scope, capacity, dependencies, and evidence.

A target can exist before the evidence is complete. A defensible commitment cannot. The Director’s job is to turn the first into the second through progressively stronger decisions—not to pretend uncertainty can disappear in one meeting.

The four-part launch definition

Before estimating a consequential launch, require agreement on four connected elements:

Element Question Weak answer Decision-quality answer
Business outcome Why must this exist now? “Become an AI platform.” “Win a repeatable enterprise workflow that supports the next financing.”
Customer For whom must it work? “Knowledge workers.” “A named pilot role with a validated, recurring professional job.”
Product contract What may the customer depend on? A feature list. Workflows, quality, security, scale, support, and explicit exclusions.
Evidence What will justify release? “The demo works.” Customer outcomes, evaluation thresholds, security controls, reliability results, cost bounds, and operational readiness.

If one element remains vague, each team will silently substitute its own interpretation. The result is local excellence and organizational incoherence: a beautiful interface around unreliable behavior, a powerful model without acceptable economics, or a secure platform that solves no urgent customer problem.

AI leverage

AI can accelerate the four-week discovery Daniel proposes. It can synthesize customer interviews, compare promises across sales materials, cluster requirements, map repository ownership, summarize delivery history, generate architecture-review questions, and model alternative scopes.

Those outputs are leads, not truth. The source material may be incomplete, private, politically distorted, or simply wrong. An accountable leader must inspect the evidence, invite challenge, and make the decision. AI can reduce the cost of becoming informed; it cannot assume the consequences of a commitment.

Human boundary

Do not delegate these decisions to a model:

  • Which customer promise the company will make.
  • Which harms and business risks are acceptable.
  • Whether the organization has the capability to operate what it builds.
  • Who owns the outcome when assumptions fail.
  • Whether evidence is strong enough to convert a target into a commitment.

These decisions combine facts with values, authority, and accountability. Assistance is appropriate. Substitution is not.

Reusable artifact: launch framing record

Use this one-page record before approving an estimate or external commitment.

LAUNCH FRAMING RECORD

Target date:
Decision owner:
Target status: strategic target / planning range / external commitment

1. BUSINESS OUTCOME
Outcome we seek:
Why now:
Measure that matters:

2. CUSTOMER
Primary user and buyer:
Job they must complete:
Evidence the problem is repeatable:

3. PRODUCT CONTRACT
Capabilities customers may depend on:
Quality, security, reliability, scale, and support expectations:
Explicit exclusions:

4. READINESS EVIDENCE
Customer outcome evidence:
Technical and operational evidence:
Security, privacy, and compliance evidence:
Economic evidence:

5. UNCERTAINTY
Assumptions that could change scope or date:
Experiments and owners:
Next confidence review:

6. AUTHORITY
Who may change scope:
Who may accept risk:
Who may make an external commitment:

The artifact does not eliminate uncertainty. It makes uncertainty governable. That is the beginning of credible delivery—and of Daniel’s real assignment.

Your next report, with a team behind it.

Wrightery is in private build. Join the waitlist and we'll bring you in as soon as a seat opens — then describe one deliverable you already produce, and watch your AI analysts research it, cross-check it and draft it for your review.

No credit card. We'll email you the moment your seat is ready.

Rather talk it through? Book a 30-minute meeting ↗

← PreviousDaniel’s Journey to Build a ChatGPT ChallengerNext →Chapter 2 — The Product in the Sales Deck