From an Idea to Business Research

Chapter 9 · 11:34–12:32

The software-development lifecycle does not begin with a coding prompt. It begins by asking whether an idea describes a real problem and whether there is enough evidence to shape the opportunity. In this walkthrough, the idea is a better pickup experience near a busy World Cup stadium.

Source boundary: The video demonstrates this flow as an example of Cortana supporting product work. The explanations and examples below separate what the walkthrough shows from teaching context added to make the reasoning explicit.

1. Start with the opportunity, not the implementation

The scenario is simple: a rider leaves a crowded stadium and needs a pickup location away from the crowd. That description is not yet a requirement. It is an opportunity—a problem that might be worth solving under user, operational, and business constraints.

The first useful questions are therefore not “Which repository should change?” or “What code should the agent generate?” They are questions such as:

• Where does this problem occur?
• Which venues or events are comparable?
• What conditions make a pickup location useful?
• Is there enough evidence to choose an initial scope?

This ordering matters. If the team starts coding before answering these questions, it may produce a technically correct feature for the wrong situation. Research reduces uncertainty before implementation creates cost.

2. Turn a Slack discussion into a research task

In this part of the walkthrough, the stadium-pickup idea is discussed in Slack. The discussion then invokes Cortana, shown at about 12:05. This is the first important platform transition: a natural-language product conversation becomes a task that the assistant can investigate.

The frame at 12:05 shows the problem discussion and the action that starts the research flow.

The assistant is not replacing the team’s product judgment. It helps the team move from an unstructured idea to information that people can inspect and use. A useful mental model is:

idea in conversation
        ↓
questions worth investigating
        ↓
comparable events and candidate venues
        ↓
evidence for a scoped product decision

The model is an investigator in this step, not the owner of the decision. People still need to decide whether the problem matters, what trade-offs are acceptable, and what should happen next.

3. Use connected context to research comparable cases

The walkthrough moves from the Slack surface to a web interface. There, Cortana uses graph-backed research to explore comparable venue events and plausible stadiums. The graph is useful here because research often depends on relationships: an event is associated with a venue, a venue has characteristics, and similar cases can help the team reason about a new case.

At about 12:24, the visible result includes a comparable event and a venue chart.

The frame at 12:24 shows broad ideation becoming a more structured research result.

The value is not simply that the assistant returns text. It assembles a research artifact that can support further discussion. The team can use the comparable cases to sharpen the opportunity:

1. Define the situation. The stadium is not just a location. It is a high-demand event setting with a crowd-flow problem.
2. Find analogies. Comparable venue events provide cases against which the proposed experience can be considered.
3. Narrow the question. Candidate stadiums and event patterns help turn a broad global idea into a more specific scope question.
4. Carry evidence forward. The result can inform the requirements and design work that follows in the next chapter.

These steps describe the reasoning pattern. They do not mean that a comparable event proves the proposed feature will work. Analogy helps form a hypothesis; it is not the same as validation.

Chat is the trigger; the artifact supports the decision

Slack is useful for starting a discussion and invoking help. A research interface is better suited to exploring comparisons and viewing a structured result. The same product task can therefore move across surfaces without becoming a different task:

Surface	Main role in this walkthrough
Slack	Capture the idea and invoke Cortana
Web research view	Explore comparable events and plausible stadiums
Later product work	Use the research to shape scope, requirements, and design

This is an important design principle for agentic systems. A conversational answer may be enough for a quick question, but an opportunity decision needs inspectable context. The assistant should help create something the team can return to, challenge, and build on.

What the walkthrough establishes—and what it does not

The source demonstrates a path from stadium-pickup ideation to graph-backed business research. It visibly shows the Slack invocation, a comparable event, and a venue chart. It does not specify the underlying data sources in the research result. Therefore, the demonstration supports the workflow and the shape of the output, but it does not by itself establish the completeness, freshness, or business validity of the evidence.

That distinction is essential when evaluating an agentic product system:

• Workflow evidence: the assistant can receive an idea and produce a structured research view.
• Decision evidence: the research is accurate, relevant, current, and sufficient for a product choice.

The first can be shown in a demo. The second requires source inspection and later validation.

Takeaway

The managed software factory starts before code. Cortana connects an informal product idea to a research workflow that uses existing context to find comparable events and plausible venues. The assistant accelerates the investigation and packages its result, but the team remains responsible for interpreting the evidence and deciding whether to proceed. Only after that decision does the lifecycle move into scoped requirements, mockups, and implementation planning.