Melissa Perri: recommendation

Transcript context

…So you have these conversations, which make so much sense. Just talk it out, see if everyone's on the same page about your goals, how you think you're going to get to that goal. What do you do with that? Do you usually recommend people throw it into a Google doc that everybody sits there and just confirms as happy, and is there a template that you share with people, like, here's what we're going to fill out by the end of this, say, three month process? Yeah, I think it varies from company to company. Some companies already have their own template, and I'll just use that. I don't try to reinvent the wheel when it doesn't need to be reinvented. But I'll say the memos that we would write are probably... They're very easy to explain, two pages for me on what's the vision, where are we going after, how are we positioned in the market and against competition to reach that vision, where are we today, what's the current state of our product, what does it actually look like, what are we going to do to get there, what's our priorities. And then I make people prioritize them, so I'm like, if we're going this way, are we solving this problem? What does that mean, context-wise? And then, what are the outcomes that we're actually trying to achieve when we get there? And I do that at different levels. So we typically have executive teams writing the strategic intents for the business level. We've got product management leadership, directors, VPs, CPOs writing the product initiatives. Usually the CPOs aren't writing them, it's more like director-level VP for their scope. Product initiatives are usually very problem-oriented around big problems we can solve for our customers. They're meaty. They're usually made up of multiple epics. And then you've got your product teams on the ground floor working with the developers. I use [inaudible 00:32:07] everybody doesn't agree on what they are. I call them options, sometimes, too, but it's the solutions. What's the solutions you're going to build to actually get into those product initiatives? Solve those problems for the users, and then hit those strategic intents. So you have to pretty much write a one-pager or two-pager like that for every one of those levels, and I think that's great. I think the more we write about these things, the more we talk about it, the more we put it into pros, the better. And it's not like a product requirements document that's 20 pages, it's like a two-pager, just explaining what we're doing and why. And that context, we usually throw into Google docs or Wiki or something like that, link them all together so that you can go from one to the next, and then read all the way up the strategy tree. I love that. It's so simple and not so formulaic that it feels like any company could do it, and it's not this rigid, one way to do it process.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.