11:34 - 13:18
From a Slack idea to research, requirements, and a prototype
Adam's walkthrough follows one proposed feature as it becomes more concrete. A conversation in Slack becomes business research, a tentative product requirement, two design variants, and a prototype plan. The example shows how shared context can travel with an idea across stages of the software lifecycle. It does not show a feature that has shipped.
By the end of this chapter, you should be able to trace that progression and explain what each stage contributes:
Slack idea
↓
Cortana + connected context → opportunity research
↓
tentative product requirement
↓
Figma mockups → A/B experiment plan
↓
existing app and backend context → prototype plan
The World Cup stadium scenario is illustrative. It is a feature walkthrough from the talk, not evidence that Uber launched this particular feature.
1. Begin with a user problem
The walkthrough begins after Uday has introduced the platform building blocks behind the software factory. Adam chooses an idea related to the World Cup. The scenario follows someone leaving a busy stadium who needs a pickup location that helps them get away from the crowd. It includes several exits, so the pickup experience has a routing problem to address.
At this point, the team has an idea, not a complete specification. An idea describes a possible user problem or opportunity. It does not yet say where the feature will launch, which screens it needs, what the backend must do, or how the team will measure success. That distinction matters because later mockups can otherwise look more final than they are.
2. Keep the idea in Slack and bring in Cortana
Adam places the idea in a Slack discussion. The participants can discuss the pickup problem there and mention Cortana, the assistant described in the previous chapter. In this workflow, Cortana is an access point to the platform's skills, tools, and connected context. It does not replace the product discussion.
The relevant context layer is the context graph. In simple terms, it connects related software and business information so an agent can retrieve more than one isolated fact. Adam presents Cortana and this context as support for deciding whether the idea is a business opportunity worth pursuing.
The workflow does not turn a Slack message directly into a product decision. It gives the discussion a path into a context-assisted investigation, so the team does not have to begin by manually collecting every related piece of information.
Caption: A presentation slide shows a Slack thread about planning World Cup 2026 stadium pickup logistics, including a Cortana assistant mention and a follow-up about using Minion.
The supplied frames show the idea becoming a shared Slack discussion. They reveal a World Cup stadium pickup experience, a routing problem involving multiple exits, a request for Cortana to provide context and specification help, and a proposal to use Minion after the specifications are ready. Minion belongs to the later implementation handoff; this chapter stops before that stage.
3. Use connected context for business research
From the Slack discussion, the team can open Cortana in a web interface and ask research questions. Adam gives questions such as:
- What other large-venue events have happened before?
- Which stadiums would make sense for this kind of experience?
This is business research. It gathers information that can help the team decide whether an opportunity deserves more work and what its initial scope might be. Cortana is helping investigate the setting in which the feature would be used, rather than generating a screen without that setting.
Caption: A Cortana interface displays an opportunity-research result based on a comparable large event.
The frame visibly shows Cortana returning a structured research card that uses Super Bowl LVIII at Allegiant Stadium as a comparable large event and lists operational observations. It illustrates the form of a context-assisted research result. It does not establish that the comparison is correct, that the opportunity will succeed, or that the feature should definitely be built.
The research step gives the next stage something more specific to work with. Without it, the team has only a plausible story about a crowded stadium. With it, the team can discuss comparable events and candidate locations. The source does not describe a formal scoring method or a final business decision.
4. Turn research into a tentative requirement
A product requirement is a constraint or decision about what a proposed feature should do or where it should roll out. Requirements translate an opportunity into something that design and implementation can use.
In Adam's example, one possible requirement is that the feature should probably roll out in North America because that is where the relevant stadiums are. The word probably matters. The talk presents this as a likely requirement under discussion, not as a confirmed launch decision.
The reasoning is:
- The idea identifies a pickup problem at a busy stadium.
- Research looks for comparable large-venue situations and suitable stadiums.
- The team uses that context to propose an initial rollout scope.
The requirement is more actionable than the original idea, but it is still not a final implementation. The team must still decide how the experience should look and how it can fit the existing application and backend.
5. Explore the experience with Figma mockups
A Figma mockup is an initial visual design used to explore a screen or feature before the production implementation exists. It helps people discuss the intended experience, but it is not the running application.
Adam describes using Cortana to help create initial Figma mockups. The presentation shows two mobile variants of the same “Beat the crowd” card. Both variants keep the card structure and change the wording that describes the pickup choice and the call to action.
Caption: A presentation slide shows a Cortana/Figma MCP workspace with two side-by-side mobile mockup variants that use different button strings.
The slide labels the workspace “Cortana/Figma MCP.” The relevant point for this walkthrough is that Cortana is connected to Figma, allowing the team to explore screen variants in the design tool.
The visible UI directly compares two Figma-generated variants:
| Variant | Status string | Call-to-action string |
|---|---|---|
| A | “Less crowded” | “See less crowded spot” |
| B | “Usually faster” | “See faster spot” |
Adam calls this an A/B experiment. An A/B experiment compares two variants of one experience. Here, the feature concept and card structure remain the same; the planned difference is the wording. The team intends to observe which wording performs better. The talk does not report the result.
The two mockups are therefore not two unrelated products. They are two candidate expressions of one feature prepared for comparison, and neither mockup proves that its wording will work.
6. Align the design with the existing codebase
As the design discussion becomes more concrete, the team needs to understand what implementation work the proposed experience requires. Adam describes using Cortana to ask questions such as:
- What code changes would be needed?
- Which screens already exist in the app?
- Which backend capabilities can be reused?
This is design-to-code alignment. It connects a visual proposal to the code and services that would implement it. In a teacher-created example, a mockup that ignores the existing app could lead the team to plan a new screen or backend capability unnecessarily. Inspecting existing app and backend context helps the team form a prototype plan grounded in what is already available.
The source describes a conversation about what can be leveraged. It does not show a completed code change. The assistant is connecting the design discussion to implementation surfaces before the coding handoff.
Adam contrasts this with an earlier process that could take weeks to align everyone. He says the combined workflow can compress alignment into a much shorter period and reach a prototype quickly. A prototype is a quickly produced working representation used to test or align on a feature before full implementation. In this segment, the prototype is the next concrete target. The segment does not show a shipped product or a completed product experiment.
The artifacts answer different questions
Shared context links the stages, but it does not make their purposes identical.
| Artifact | Question it helps answer | What it does not establish |
|---|---|---|
| Slack idea | What user problem or opportunity should we discuss? | That the feature is worth building |
| Research result | What comparable events or locations can inform the discussion? | That the research is a final business decision |
| Product requirement | What initial behavior or rollout scope should guide design? | That the requirement is confirmed or complete |
| Figma variants | What interface options should we compare? | Which option will perform better |
| Prototype plan | How might a proposed direction fit the app and backend? | That the feature is implemented, validated, or shipped |
The factory pattern here is a sequence of increasingly specific artifacts. The idea remains traceable while the team adds evidence, scope, visual choices, and implementation context. The platform reduces the work of gathering and connecting that context. It does not remove product judgment.
What this example does not claim
Several boundaries matter when reading the walkthrough:
- The World Cup stadium pickup scenario is illustrative. The transcript does not report that this feature shipped.
- The North America rollout is phrased as a likely requirement, not a confirmed product decision.
- The research card and Figma mockups show possible outputs, but the talk gives no research-quality result, A/B winner, or product-market outcome.
- The phrase transcribed as “Cortana 2” is uncertain. It may mean Cortana as well, rather than a separately named second assistant. This chapter therefore treats it as Cortana helping with design and codebase questions.
- The segment ends as the team is ready to build. It does not provide the later code diff or prove that the prototype works in production.
Check your understanding
Why is the North America statement a tentative product requirement rather than a final fact?
Answer: Adam presents it as what the feature should probably do because of the stadium context. The talk does not confirm a rollout decision.
Why do the two “Beat the crowd” screens count as an A/B experiment plan rather than two separate products?
Answer: They keep the same feature and card structure while changing the button wording. The plan is to compare those variants; no winning result is reported.
Synthesis
The example moves one idea through a connected sequence. Slack captures it, Cortana and the context graph support research, research informs tentative scope, Figma makes alternatives visible, and existing app and backend context shapes a prototype plan. The workflow becomes faster because context follows the idea across stages. It still preserves the difference between researching an opportunity, deciding requirements, comparing wording, and building the feature.