Anatomy of a Prototyping Engagement: AnyCompany & AnyProto
Part 2: The Discovery
This post is part of a series walking through how I approach a PACE engagement end to end: the considerations, the decisions, and the consequences of getting them right or wrong. Details here are anonymized and composited for illustration; AnyCompany and AnyProto are stand-ins, not a real customer or product.
← Part 1: The Ramp Up | Series index | Part 3: The Scoping →
Scene
The Technical Project Manager has arranged the meeting, inviting me, my manager (optional), and the key stakeholders from AnyCompany. An agenda lays out the structure of the meeting. It's time for the discovery meeting, and time to hear from AnyCompany.
Ideally they have a presentation of their own to help get me up to speed, but it's fine if they don't. What matters is that I can understand and sympathize with their issue, and that I can understand the technology that presents the limitations and opportunities.
AnyCompany walks me through their media archive library, discussing the variety, length, quantity, and contents of the videos they've acquired. They mention that they have interns currently going through the archives, manually tagging each video with metadata like the source, subject, and persons appearing.
The VP of Video states that on occasion, his team gets requests for certain pieces of content for b-roll footage, and that it currently takes quite a while to acquire the right footage. Even when the footage is found, much of it has to be edited down to isolate the relevant scenes.
The VP states that his primary goal is to eventually create a marketplace where users can subscribe to access video archive clips. The first landmark on his roadmap is finding a way to make individual scenes in a video searchable and exportable.
After the walkthrough, the meeting opens up for questions from my side.
Now What?
Take notes, then reflect them back. Different people have different styles, but I'm definitely taking notes during the walkthrough, to see if I can answer any important questions without having to make the VP repeat himself.
Whatever notes I've taken, and knowledge I've gathered, I repeat back in my own words to check for comprehension. Often, this prompts the speaker to elaborate further on things they may have omitted the first time. Either way, it's good to give them a chance to correct any assumptions I'm making.
It's also important to write down any lingering questions, since during a conversation they can easily slip away from memory.
Use the Working Backwards questions as a litmus test, not a script. I won't talk at length about the five Working Backwards questions, since there are plenty of other resources that cover them better, and in practice (while useful) they were a bit of a formality for me during discovery. Still, they're worth calling out briefly:
- Who is your customer?
- What is the customer problem or opportunity?
- What is the most important customer benefit?
- How do you know what your customer needs or wants?
- What does the experience look like?
I treat these questions as a litmus test for how well I understand the customer and their use case. If I don't have confident answers to all five by the end of the discovery session, I likely need to allocate more time for another one.
Having teammates with me during discovery, my manager or the technical program manager, is important. They can help answer some of these questions if the answers are unclear, and they can also acknowledge when not enough good information was provided and arrange for more time if needed.
Discovery sessions can be difficult, but they also put responsibility on the customer to be prepared to communicate their use case. Customers might not have all the answers immediately, and sometimes multiple stakeholders will be misaligned and point me in opposing directions.
There are also times when a customer is so deep in their own subject-matter expertise that they have trouble communicating it in layman's terms. I am catching them in the middle of their workday, after all.
The questions I may actually ask for this use case:
- "What is the average length of the videos stored currently?"
- "Where are the videos being stored? How are they being retrieved?"
- "Are there any naming conventions for the video files from the acquisition? What are the file formats?"
- "I'm assuming these videos also have audio, are they all in English?"
- "What do the requests for b-roll footage look like? Do you have examples you can share?"
- "Let's say a request comes in right after this meeting, how do you handle it?"
- "You mentioned it takes a while to get the right footage. Could you quantify that? Minutes? Hours? Days?"
- "You mentioned interns manually tagging videos, how long does that take? What's your estimate on cost?"
Each of these questions is in service of one of three things: helping me measure the success of a solution, helping me architect it, or helping me set appropriate boundaries on what can and can't be built in the engagement's timeframe.
Measuring success. Knowing that I can enrich a video with metadata in 10 minutes on average doesn't convey much impact on its own. It only lands once I understand that tagging previously required watching the full video, which could take a whole hour on average.
Architecting and scoping. If I know the video file formats are all .webm, I know I may not be able to use Amazon Transcribe (as of July 2026) to extract spoken words from that video, which changes the architecture slightly.
If only a small percentage of files are .webm, I may want to negotiate deferring support for that format until after the initial prototype is built, and instead provide guidance on what that support would look like.
These kinds of questions directly feed the scoping proposal: the next formal meeting between me and AnyCompany. A good habit is to have the scoping slide deck template open during the discovery meeting itself, to make sure I'm capturing enough information to complete it. There won't be much more information gathered between this meeting and the scoping proposal, so it's worth making sure this meeting gets recorded too.
Balancing listening against solutioning. It's a tricky balance during discovery between learning about the problem and starting to brainstorm solutions. Spend too much time only discussing the problem, and I may end up with blind spots around the technical direction AnyCompany actually wants
It's happened to me plenty of times in the past, some important data warehouse goes unmentioned, or required data or account access gets requested too late and pushes delivery back.
It's important to prime AnyCompany now on what a solution could look like; it's like throwing a stone into a pond and kicking up a sediment of details that are usually quite relevant to the build.
Begin solutioning too quickly, though, and I risk pigeon-holing myself and AnyCompany into a solution that seems to solve the immediate problem but doesn't scale well or integrate into their existing systems.
Similar blind spots apply here: use cases go unmentioned, and the long-term vision suffers. An example here would be focusing so much on the science of indexing video that the marketplace's user experience and distribution infrastructure become an afterthought, when the business value all along was providing value to end users for profit.
Don't panic in unfamiliar territory. A last note: it's important for me not to panic if I find myself in a domain that's entirely unfamiliar. The discovery session isn't the time for me to have the right answers. It's actually a poor time for answers.
What matters is that I come out of the session knowing exactly what I need to research, who I might want to reach out to for help, which aspects of the problem are most important to solve, and exactly what I need to show AnyCompany to set them up to succeed on AWS.
← Part 1: The Ramp Up | Series index | Part 3: The Scoping →