Skip to main content

Building a Cross-Functional Story Bank

Premium

Now that we know:

  • Why Google cares about cross-functional collaboration and what comprises a high-performing team.
  • Details on Google’s company and product culture.
  • How each member of the product team contributes to product success.

It's time to put it all together!

Remember that Google looks for thoughtfulness, self-awareness, and experience with cross-functional collaboration. You’ll be asked experiential questions about what you did in the past, such as:

  • "Tell me about X"
  • "Describe a situation where X"

…as well as hypothetical questions testing what you’d do in a given situation, such as:

  • "How do you resolve conflicting product requirements? What or who determines which requirement takes the hit?"
  • "Your largest customer is loudly advocating for a new feature that is not in your prioritized roadmap. Sales, eager to please, have gone straight to Engineering to see if they can drop everything and get this done. What do you do?"

Note that Google is testing your general approach to cross-functional collaboration, but you’ll probably get questions on handling conflict, prioritization issues, and handling distraction. More on these later.

The best way to prep for these is with a story bank, or a list of stories that you know well and can speak easily about for your upcoming interview. While you can't anticipate the exact question an interviewer may ask, you can at least have a few stories in your pocket to share that best fits the question.

Pick Your Stories

Choose 5-10 experiences that made an impression on you, and that reflect at least one company value. Include success stories, but don't stop there. Make sure you have at least one story mapped to each company value.

Be sure to pick examples that are diverse. If you’ve worked at startups and big companies, you might choose one from each. Stories with varying team size, type of problem, or even the emotional sentiment of the story (e.g. preparing for a weakness-based question) give you good coverage for followups.

Tip: Remember - the best stories are ones that, when you tell them, you feel confident and knowledgeable about. Thus, we recommend picking stories that are vivid and clear in your mind, and ones that you'd be happy to answer follow-up questions about.

Add Detail

Once you've chosen your stories and mapped them to company values, it's time to fill in the details. You're probably able to talk through your product decisions without much practice, but remember - right now, your focus is on collaboration.

As soon as you’ve written the high-level context (problem, solution, and results), shift your focus to the "people" aspects. Begin by mapping out all the stakeholders involved in the story. It may be helpful to diagram stakeholders visually, like this:

PM Collaborators

It's helpful to specifically write down the who, what, when, where, and why, for each "act" in your story. Take care to record how this project or task fit into larger business goals and why. This context will help you answer follow-ups later. Make sure your actions clearly show you embodying company values. Were there disagreements? Were mistakes made? Were you in a leadership position?

Choose at least one story where things didn't go your way and a few where you learned significant lessons. Interviewers want to hear recent stories, so stick with stories two years old or less. The best stories are vivid and nuanced. You shouldn't be able to sum up the entire experience in a sentence or two.

To recap, choose 5-10 stories that you can describe in detail, that map to company values, and that cast you in a good light when reflecting on high-performing teams @ Google. Write them out in as much detail as you can, taking care to cover the context, problem, solution, and results, and anything important related to team dynamics.

Rewrite Using STAR

If you've captured all the detail you can remember, you're probably looking at several messy pages. You'll need to tighten these up before your interview. We recommend rewriting using the STAR framework. STAR stands for:

  • Situation
  • Task
  • Action
  • Result

This format maximizes the information content of a short answer, which will make you more memorable and keep you from rambling. Because it's simple, it's also easy to practice.

Situation

Begin with context, taking care to emphasize team dynamics. What was your role? Were you a team member or leader? What prompted the situation? An executive initiative (potentially high-pressure) or customer-led (collaborative opportunity)? Set up the situation so that your interviewer knows how to frame your past experiences.

Task

What was the specific problem your team was facing? Try to incorporate insight into the interests of various stakeholders. Did users hate your new feature? How did that affect your designer? Did a database that stored sensitive information crash? How did engineering respond?

Action

Time for the nitty gritty. Challenging projects require creativity. Describe in detail how you arrived at your situation, emphasizing how you communicated and acted intentionally to bring about the best solution for everyone.

Results and Impact

Finally, cover results and impact. What were the positive outcomes? Use specific numbers, revenue, or tangible examples to highlight your point. In behavioral interviews, it's helpful to quickly summarize what you learned as well as what results you got. How did this experience shape your management-by-influence skills?

Next Lesson