In the latest edition of the Full Stack Leader, we talked to Lauren Creedon, Head of Product at Goldcast, about planning and execution.
Lauren talks about the significance of understanding the business’s operational plan, market dynamics, and user behavior seasonality. This knowledge is crucial for effective product launches. Lauren also advocates coaching teams to achieve significant outcomes within a quarter, emphasizing the need for structured planning and phased execution.
In the interview, Lauren emphasizes the importance of understanding target markets, budgeting cycles, and competition in the AI product market, advocating for clear communication over technical jargon. She introduces the concepts of seasonality and roadmaps, stressing alignment with usage peaks and budgeting cycles for optimal impact.
Top leadership tips from Lauren Creedon
Below is a summary of the top Leadership tips shared during this week’s interview. Listen to the episode to learn more about the thoughts behind these tips:
- Know your operating plan and seasonality
- Coach your team to hit big outcomes in a quarter
- Use end-to-end value increments
- Do 1-5-50 user testing
- Don’t be too smart for your own good
We hope you enjoy the episode. You can find more Full Stack Leader episodes here.
Part 1. On the career and experience
Ryan: Hello, everyone, and welcome to this week’s episode of the Full Stack Leader podcast. This week, I’m excited to be here with Lauren Creedon. She’s the Head of Product at Goldcast. Lauren, it’s great to have you here.
Lauren: Thanks, Ryan. It’s great to be here. How are you?
Ryan: I’m doing good. I know we’ve got a lot of really interesting stuff to talk about this week, including what you do at Goldcast, AI, and ML, as well as the path of a product leader.
So, I’d love to dive in if you’re up for it.
What Goldcast does and how it’s doing
Lauren: Absolutely. Yeah. So, as Ryan mentioned, I’m Head of Product at Goldcast. Goldcast is a B2B events and content platform. Marketers will come to Goldcast, record and post live video events that drive the pipeline, and then auto-generate content from those events.
I started at Goldcast last year after we raised our $28 million Series A. It’s pretty cool to find myself leading the product team. It’s exciting for Goldcast. Personally, it’s been exciting as a former founder-then-growth-stage operator to land at this third stage of my career and lead my own product team or help the company scale to that Series B, which is going back to those early stage roots and trying to use the playbook I developed at growth stage companies to help us hit our plan.
Ryan: Yeah, I love that. It sounds like you’ve got experience at pure early-stage entrepreneurial startups, as well as growth stage and then into really moving a product into that later phase of, I assume, pretty major acquisition of clients or customers.
Importance of learning how to fail
Lauren: That’s right.
I expect other product leaders out there will relate to my journey. I got started in school even, fascinated with starting my own company. Through a few years of trial and error there, I’d like to say I really learned how to fail. I learned to wear many hats. I have that startup DNA at my foundation.
But by learning to fail, you also learn what it feels like to waste money on failed ideas or years of valuable people’s careers on poor execution. You really humble yourself, learning to fail. And so, a move that other people might find familiar, as well as pivoting and then really going to lead teams at growth stage companies, learn how to launch products from conception to scale with an active customer base, learn from other leaders’ playbooks- and that was pivotal to getting back to this point where I really feel the startup energy again in a leadership role. Yeah, it’s been a really fun journey.
Ryan: I’m super excited to talk about this. Maybe we can jump back a bit and give us some perspective as to some of the really early entrepreneurial things that you kicked your career off with and how that actually led you into a kind of more advanced product.
Impact of previous workplaces
Lauren: Sure. There were a couple of startups that I co-founded, both in college and right out of college. I like to define that stage in my career as where I caught the entrepreneurial bug. And that’s where I got into sports tech. I worked for a couple of different early-stage sports tech companies.
One of them was in the live video space, which got me into live video, and after the experience of watching those companies fail, I made the pivot into my first growth stage company. And so the two growth stage companies I worked at between those early startups and now Goldcast.
One was a company called Huddle, a video software company serving the sports market. And when I left there, I was leading the team working on AI/ML smart cameras. That was my first foray into AI/ML while in live video. Then, after that, I was leading the AI team at Drift, which is when I got into B2B SaaS. There, we used NLP technology to help companies really have conversations at scale via AI chatbots and understand the context of those conversations.
But for each one of those – both the early-stage startups and the companies at scale – I can directly point to how they helped me develop this playbook that I use today at Goldcast.
Ryan: It sounds like Goldcast is a combination of these two things all in one, which is great.
How core video space has changed
Lauren: It is. It’s funny you say that because when I connected with Goldcast through a mutual friend investor, I realized, “Wow, live video applied to B2B marketing. plus the AI component, it’s all the elements of my journey, “so I had to take the call.
Ryan: Yeah. What’s interesting, too, is you really were in this core video space right before the pandemic, before people adopted it at such an intense level. Did you see some change while you were doing it between that point and post-pandemic, or even during the pandemic?
Lauren: That’s a great observation. That’s part of why Goldcast had such success when they started a couple of years ago. Yeah, the most interesting change has been in the expectation for super high-quality performance video. So that’s surely been a challenge for Goldcast to compete with companies like Zoom that have just raised the bar on what’s expected for video quality over low internet, et cetera.
And another one, of course, has been the rise of open-source AI. So, even in the time between working at leading the AI team at Drift, where all of our NLP was in-house developed, to now where we’re developing things at Goldcast using GPT within a quarter, it’s just like the pace of innovation in AI has changed drastically.
Ryan: It’s absolutely wild. As you can imagine, it’s a very common conversation on the show, but I am blown away because we’ve been developing a number of products that were AI related, whether NLP or computer vision, pre-March of this year, and then, and it’s like the ballgame changed right in that month.
AI and its influence on tech
How do you think companies that have developed homegrown models and systems are going to fare against these newer, bigger methodologies that you can tap into via API now?
Lauren: Well, I have some strong opinions on AI. One of them is that the technology itself is not going to be where companies win.
But the most successful products will be the ones that nail the workflows and the specific use cases in which you’ve applied that AI. So, the ones who win won’t be the ones who own the best tech. I’ve even watched my past team – and I still mentor some of my past team at Drift – I’ve watched them incorporate GPT, where they have their own in-house AI, but incorporating GPT has allowed them to scale faster and adapt faster to those workflows that users will adopt.
So it’s my strong opinion not to over-index on owning the best technology, but to really understand your specific customer job-to-be-done and nailing that workflow so you apply it right in line with the problem they’re trying to solve.
Market strategy is the key to success
Ryan: That sounds about right. What would you say, as you were getting into the AI space – maybe, in the earlier days of it before it was so ubiquitous – was a lesson that you had to take with some of the product teams you were working with?
Lauren: It relates to this strong opinion I just mentioned.
So, the meat of my career now has been leading these highly technical product initiatives from conception to scale the computer vision, smart camera, NLP-based chatbot, and now generative AI video products at Goldcast. All of them share this common theme that the success of the initiative is not based on how good the tech is but on the market strategy and the supporting product roadmap to execute that market strategy.
So, the tech has to meet the bar. The tech has to be good enough to be feasible. It has to be getting the job done. It has to be better than or as good as your competitors. But when I say “the market strategy,” – it’ll come up in some of my top five tips later, but really, my product playbook is all about aligning with go-to-market strategy when you’re in a highly competitive field against competitors, which all of AI products are doing right now, It’s all about speed to hitting a customer and wowing that customer.
Oversimplifying as the best strategy
If you really know the markets you’re trying to sell into, and you really know their budgeting cycles, and you really know who you’re up against and what customers are, what workflow they’re applying you to, you, you need to develop a really lean roadmap to staying on pace to those goals, testing, iterating.
And then don’t forget about the other half of that market strategy, which are your go-to-market teams and your cross-functional partners. This is why it’s not about the best technology winning because I believe the most successful go-to-market strategy for winning in an AI product market space is oversimplifying.
You can’t be hand-wavy with overly technological terms. Now, you have to be very simple in your pricing, packaging, positioning, and internal enablement about how the product works. I’ve seen this work. So, if you get really clear on the seasonality of your roadmap, the specific problem you’re trying to solve, you iterate so that you are the best at doing that for your customer, and then you enable the team around you to cleanly sell that into specific markets with really great packaging, that is going to be the success for an AI product today. Anyway, I can talk about that for a while.
Ryan: No, that makes a ton of sense. I actually think everybody listening to this should go back and listen to the last 10 minutes or the last 15 seconds because the way you sum that up was incredible.
And I want to go a little bit deeper on one of the things you mentioned, which was the seasonality of your product roadmap. Can you say more about that particular piece?
Seasonality and why it’s important
Lauren: Absolutely. Seasonality was going to be one of my top five tips, but that’s great ’cause I had more than the top five tips. I’m going to knock this one off now. I believe all product leaders should know your operating plan and your seasonality. Usage seasonality and budgeting seasonality.
So, you have these markets you’re selling into. And then you have your forecast assumptions, and those are two timelines that layer over each other.
Let’s start just with the markets you’re selling into. A really great example of how I arrived at this theory is the sports market I used to sell into. It’s very clear when usage seasonality is because football season starts in August, and if your products aren’t ready to go, then your users aren’t going to be able to use them.
But that same thing applies to Goldcast, where we have peak event season in the spring and fall, and that’s when you see our usage peak. There are certain product initiatives that need to be ready for peak seasonality or a little bit before. And when you lay that out on the timeline, all of a sudden, your roadmap starts to work backward from those seasons.
Minding the budgeting cycle
But there’s another one that layers in, and if you go back to the sports analogy, what we learned at Huddle is that if you launch something right in time for football season, but nobody knew about it during the other season, which is budgeting season, then you’re not even going to have the adoption you want if people didn’t know to buy it in the spring, which is X number of months before. That’s where the go-to-market piece of it comes into play: if your competitor beats you to the purchasing cycle, to the budgeting cycle, it doesn’t matter if your product’s ready to go by peak usage seasonality. You never want to get into a waterfall-type roadmap, hopefully, where you’re planning everything a year in advance. At this stage of the company, we all have a 12-to-18-month timeline where you have to hit your operating plan, and there are only a couple of budgeting windows within there, two to four, and a few peak usage seasonalities.
So you got these at-bats, and if you work backward from them, not only for the product scoping of thin increments to be able to ship in time for people to use it, but also in terms of enabling your teams to sell when it’s relevant to your buyer to be making that decision, you can sell a little bit on your roadmap, and this is very applicable in B2B because enterprises have such long deal cycles, but To this day, my go-to-market partners across the business, the one slide they always come back to is the seasonality slide because it crystallized for them how to align our campaigns, how to align launches on the product team. It helped us understand what those big rocks are that we’re going to deliver that we can’t fail against.
I could wax on about this one. I love seasonality for helping drive business outcomes.
Building a product roadmap in advance
Ryan: Yeah. And it also requires – and maybe you can talk a little bit about this – your business partners to have their visioning done in advance. Correct?
Lauren: Great point. And that’s part of why I love being on the leadership team at Goldcast is I can, I really have that opportunity to partner with our CRO, with our sales leaders, with our marketing leaders and do that work in H2 of the year before we’re building our product roadmap. I think product leaders really need to get wise on the operating plan, but that’s only half of it.
It’s also helping encourage and help your cross-functional partners see that if you don’t land on the operating plan until the end of December and we haven’t partnered together on it, I haven’t been able to plan my roadmap in advance. So, there are some key assumptions that we need to align on ahead of time.
“What markets are we selling into?” – That’s most of it- and “What’s our expected win rate we need to be at in those markets?” so that the product team can do their research in H2 of the year before you need to be hitting those numbers in that market. In some markets, you get longer deal cycles – in the enterprise, you get like a six-month deal cycle. So, if you’re starting to sell the enterprise at the beginning of the year, you have some wiggle room but tighter deal cycles. If you want to start hitting your number right out the gate and Q1, the product team needs to be looking at that a couple of quarters before and making sure they know that market expectations, new competitive players, et cetera.
So, it all comes back to the assumptions that those business leaders are using and trying to pull them out, draw them out ahead of time, and crystallize them early enough.
Leaving room to pivot and innovate
Ryan: Yeah, that makes sense, but given the speed of evolution of things right now, and maybe going forward at this point, it may never slow down again, even remotely.
Do you think even those timeframes are going to become too long, and the visioning has to get closer to real-time? Or do you think that there’s still a benefit to trying to look a little more distant in the future and then develop toward it?
Lauren: It’s a great question. I think you always need to leave room to pivot and innovate. Even in our own strategy this year, we set goals for the year last Q4. So now we’ve just completed Q2. We’re halfway toward hitting those goals. We’re actually on pace or ahead of those goals on the product adoption side, which means we can already look ahead.
We can start to innovate ahead of next year’s roadmap a little earlier since we’re on pace, and sales will still need to use the remainder of this calendar year to hit the forecast. But because we’re on pace with the adoption metrics we set, we’re actually able to create some room in our roadmap to respond to changing market trends.
Staying unsurprised
You always need to leave room for that. I like to say this phrase. ” Be unsurprised. “It’s a phrase I stole from a Glennon Doyle podcast, but she meant it for your family relationships: “Be unsurprised when things happen to you until you get triggered.” But it really applies to work, too. Be unsurprised that this market is gonna shift, be unsurprised that there’s gonna be risk, protect your core assumptions of hitting your number this year.
Okay. If you’re on pace with both renewals and new sales and you’re hitting the product adoption that it takes to renew, then allow room to pivot; allow yourself that space to adjust.
Ryan: Yeah, great advice. That’s great advice because change is guaranteed.
Lauren: let me add something to that. Ryan, that even is a little hand-wavy of the “unsurprised” and “leave room to respond to risk.” I think one of the tactical recommendations I use for product teams is to try to coach my team to hit big outcomes within a quarter. You’re never more than a quarter away from a successful pivot if you need to.
Ryan: And I can break that down a little, yeah, let’s go a little deeper there. So, you’re saying that always consider the timeframe of the potential pivot as three months, no matter what.
Planning outcomes within a quarter
Lauren: When you think of an annual plan, which we were just talking about, I break that down. Many companies do break it down into quarterly plans where you get a chance to adjust, see how you’re pacing the goals, and adjust. And as you prep for that quarterly commitment, say, on a product team, you get a chance to commit to an outcome. And I coach my teams to say, “What outcomes are we committing to within this quarter?”
And if we learn something in Q1, say, that means we need to tackle something different in Q2 or prove something or take something from conception to scale within a quarter. There’s a pretty tactical framework you can use to do that. It breaks down essentially into four months because I’m including a month zero – before the quarter starts where you are, you’re planning what that quarterly outcome is going to be, you’re scoping a potential product initiative, and that you’re reducing the risk that this product initiative is viable in the market.
So if it’s investable, if you validated that users would pay for it, the key job you need to do. You can get ruthless about prioritizing the scope for the quarter. Cut out all the nice-to-haves; cut it down to the minimum value increment that users could actually get a job done with. If you have that, and the team can say, “Yeah, okay, I can commit to that.”
And then you have the quarter to execute. That’s when you get your month 1, month 2, and month 3 to hit an outcome that you’ve all decided, “Okay, we’re going to go for this within a quarter,” I say month one is about feasibility risk; month 2 – usability risk and month 3 – adoption risk. And I can break each of those down, but you get like six sprints in a quarter.
Month 0: Planning and validating
Ryan: How much do you have to partner with your engineering leads and your marketing leads for that to come together?
Lauren: Oh, hand in hand every step of the way. In that month zero, you’re partnering with your marketing counterparts and sales counterparts to validate which user segments would go after this.
I’ll bring it and make it real. At Goldcast, we’ve, in the last quarter, launched an AI product. That was a complete pivot, not part of our annual plan, but responding to changing market conditions. we partnered with marketing on the research to validate that, even though this is a separate user job-to-be-done, going from hosting live video events to regenerating content that customers wanted and would pay for it and that it wouldn’t disrupt the platform we’re currently selling.
We even put a demo sales deck together, and we tested that out in month zero. We then worked with our engineering partners to figure out what the roadmap would be to reduce feasibility risk and commit to how far out we wanted to plan.
Month 1: Feasibility risks
Partnering with engineering is where you start getting into reducing feasibility, usability, et cetera. In that first month, if you want to do it within a month and keep your team focused on that prior quarter, then the first outcome you partner with engineering on beyond scoping that you have room to take this on our team to take this on is diverging on a couple of solution alternatives.
POC (proof of concept) is putting that in front of customers, reducing the feasibility risk. Is this possible to build? Are we going to be successful? And you get your own internal users using it in that first month, maybe even a friendly alpha customer, but you’re partnering not only with setting those sprinkles with engineering but every single day. What tradeoffs can we make to make it align on a solution path? What can we do to unblock our team? How do we introduce quality from the beginning?
Month 2: Usability risks
Month 2 gets closer to design. It’s what I call the usability risk. You give something that’s feasible and working end to end to a few beta customers, and you work with design to say, “Is this usable?”. “Yes, it can be done feasibly, but, oh, they’re having trouble here.” And you really let your customers fail as they’re trying to use it. You highlight that, and you focus month 2 on reducing any of those blockers so that it feels like a usable working product.
Month 3: Adoption risks
And then, month 3, it’s just all about adoption. You get a couple more at-bats to introduce either a new feature or another value increment that was maybe more of a “nice to have,” but then you see users weren’t adopting it in the data before you take it to general availability, you get a couple more swings. to increase adoption when you go live.
That all has to be done. If you’re in partnership with your whole team to reduce scope, to get a really thin slice, make sure it’s end to end, and don’t overinvest in one thing without forgetting that the full workflow wasn’t complete. It can be done. You can pivot within a quarter, hit an outcome, and then decide how much further to invest beyond that.
Ryan: Wow, that’s such a great system. Again, I recommend people, especially in the product world, go back and take note of the last few minutes. Now, as an advanced product person, I get what you’re saying. “First, go around” makes total sense. And it’s really thoughtful approach.
But how do you work with new product team members that might be coming on and are just being introduced to something with this kind of urgency or they don’t necessarily know how to work that into their flow?
Do you train them on that? Do you hire for that particular thing? How do you deal with it?
“Chaos is a ladder”
Lauren: It’s a great question. I think you can coach almost anyone to operate this way. But it does come back to coaching and management. There are a couple of tools I coach my PMs on, and there are a couple of visual reminders I give them, but I think it all starts with helping people be outcome-focused.
When we’re junior, and we haven’t learned these skills yet, we might be all consumed with a specific product we’re working on, a specific set of tasks, or being as helpful as possible to the team. And it’s really chaotic to try to do everything that PMs / junior PMs are asked to do.
I say the word “chaotic,” and it reminds me of this quote from Game of Thrones. I’ll make this relevant. But have you ever heard that quote? “Chaos is a ladder.” it’s basically this character saying that people can grab power within chaos based on their bravado, their connections, and their will.
We see a lot of leaders emerge through this chaos because they’re able to hit outcomes or convince people to do something, and then all of a sudden, they’re the ones with the outcomes. They’re the ones that have gotten things through, and they get promoted. And we see junior PMs continuing to try to flounder.
Outcomes should be rewarded
As leaders, I think it’s our responsibility to show PMs that outcomes are what get rewarded. We put that into career ladders. We put that into outcomes that ladder down from the high-level business operating plan to our product OKRs, to our team structure, to our individuals, and what we’re coaching them to achieve.
We tell them at the beginning of the year -on my team, at least.- Outcomes are what matter. Look out for a year. What outcome would you be proud of? How does that ladder up to one of the business outcomes?
You’re asking about whether it can be taught how to operationalize something within a quarter. Well, we’re having those conversations with our junior PMs at the beginning of the year, and we’re saying, “We have biannual reviews, so we have one every six months, which means you get two quarters within that six months to really ship an outcome.” And we use this other device called big rocks versus small rocks.” have you ever heard that analogy where you’re talking about a glass jar, and if you fill up your glass jar with sand first, you can’t put any big rocks in, but if you put the big rocks in first, then the sand and the little rocks can fit around it?
That’s how I coach our PMs to think about outcomes. I say, “Okay, here’s the big business goal. What’s a goal on your team that you own that ladders up to that business goal? What’s a product initiative that can impact that business goal? How would you know that you’d hit that initiative? How can you ship something that’s going to have, that’s going to be, have a big rock impact within this quarter?”
And we work backward from their career progression to help coach them to focus on those outcomes. And I tell them, “Everything that comes up against one of those outcomes, try to practice prioritizing against it.” So I come back to that quote, “Chaos is a ladder.” As leaders, if we do ladders right, we can avoid that chaos for our teams.
We can help it be more fair and equitable and less biased, and coach PMs to think about how outcomes ladder up to that overall business goal that everyone’s motivated to achieve and help more PMs to be good leaders, to outcome-driven leaders.
Measuring the outcomes
Ryan: What are some of the best ways for you to help them work in the measurement tools that they need to get those outcomes at the end?
Do you build that in as part of their process?
Lauren: I do. It’s a pretty simple process that’s hard to stick to, but we, as a company, have annual OKRs. We break them down into quarterly goals, but we don’t recreate the wheel every quarter. We have an annual OKR for a reason. Say you learned – like we learned at Goldcast – that everyone learns more usage equals higher renewal.
But for us, there was a magic number, right? Our key number of events that our customers had to run to lead to a successful renewal. We set an annual OKR around that. Instead of creating separate quarterly goals, we measure pacing toward that goal.
How much of a cohort is on pace with that number of events after Q1, after Q2? What are the product initiatives that ladder up to that? And so we build it into our rituals. You have your quarterly QBRs internally, where we ask product managers to report on that pacing, but within the quarter, it’s not enough if, after the quarter ends, you say you’re off pace. So, within the quarter, we build in rituals where we report on pacing to a goal. And we do that at spring demos so that the engineering teams are a part of that, too. It’s not just on product and business leaders. Everyone gets motivated when they see the meaning of their work tied back to a business school.
Power of repetition
If you want people to remember something, say it seven times in seven different places, seven different ways. So we do it in our QBRs. We do it in our sprint planning. We do it in a sprint demo. We measure not only our pacing to goals so far, but how we expect the adoption of a particular initiative we’re working on to impact that OKR.
I try to oversimplify it. Just have those annual numbers measure pacing to them. Understand how what you’re working on will impact them. Often, we get so convoluted, and we show a bunch of numbers, but we don’t know how this particular usage metric really ladders up to that business goal.
If we coach our teams to show that, it can take a lot of teams on a few different initiatives to help customers run more events successfully on your platform. And so laddering up is the key.
Ryan: Yeah, laddering up. I like that.
Here’s my last question for you before we get into your top five tips. So, I completely understand when you’re successful with hitting usage goals. That makes the team feel good about themselves. They’re right on the right way, but what happens with you, and what’s some advice you have if you’re in the middle of the quarter and it’s just not going to work out?
What do you do in that moment, given you have all these resources pointed at that thing?
Feeling comfortable failing
Lauren: I’m so glad you asked this. I feel strongly that we as leaders need to make our teams feel comfortable failing. Part of why we should measure pacing to goals is to feel comfortable calling out risk as soon as possible, calling out where we’re off the pace with enough time to make a change.
And so the more comfortable you help teams be where it’s not like you’re doing something wrong if you’re off the pace, you’re actually rewarded and doing something right. Suppose you say, “We’re not on pace to this goal. And here’s what we’re going to do about it.” And so the way I think we as leaders can make our teams feel more comfortable with that is if we ourselves fail in public, so I came up with this term “work in public” at my last company where I felt like we’re always expected to show up and put on a mask. Like, we have all the answers. If we show our work in progress, we always tell our teams that we expect them to show their work, but we, as leaders, don’t show our work a lot.
If you work in public, if you make Slack posts about things, if you use Loom videos and share where you’re at, if you pull up, spin up a whiteboard doc, and just start putting things on paper and reduce that barrier to feeling like things have to be really polished.
If you, as a leader, are working in public, showing your work, measuring where you’re off pace, you’re going to help your team do the same.
And then you’re going to help get them comfortable proposing something to do about it. So instead of just saying, “That’s urgent, that’s bad, go fix it.” Say, “What might we do about it? What are some ideas you have? what else could we do to get back on pace?” What might we have to deprioritize and be comfortable helping them say what’s not going to happen and knowing that tradeoffs have to be made in order to determine if that goal really is still important – that’s the choice, right?
You either say, “We’re going to stop investing,” which is also people should be rewarded for choosing to stop investing to not just hitting outcomes, but the saying “We learned something we chose not to,” or “If we’re going to keep investing because that’s the most important thing, what gets traded off.”
Designing different scenarios
One more tip on here while we’re talking about failing in public and showing our work, which is coaching our teams to show scenarios. So, not just. “Here’s the one thing I’m proposing,” but come to a leadership meeting, something you’re off pace to, and show a couple of scenarios.
“Here’s scenario one. We keep doing what we’re doing here. The risks with that, that the duck here, the benefits.” “Scenario two, we pivot. Here are the risks with that. Here are the advantages.” And then to say, “I propose scenario two,” and then allowing people to say what they don’t like about it, weed out what your counterparts are going to have a problem with.
And ultimately, then when you align on a path, You’ll know what the risks are. You’ll know what objections you have to overcome, but it starts a conversation. Harvard Business Review said if you look at scenarios side by side, it reduces bias compared to looking at them sequentially like people will just say what they don’t like about something.
There’s a whole concept of failing in public. Then, there’s coaching your team on how to fail and show them how to assess alternatives. Yeah, there’s a whole, there’s a whole coaching structure here. I’m trying to think about where I’ve learned some of these things, but it’s an amalgamation of tips from other great leaders along the path.
Ryan: So good, yeah. And HBR, by the way, is an amazing resource that I’ve used for many years as well. So there are so many good topics on there. Well, listen, it was wonderful to hear your thoughts on this. I think we could keep going for days on end. And maybe it’s worth coming back and doing a revisit in the not-too-distant future.
But we really appreciate your feedback and advice and a really good, tangible breakdown of some awesome systems here.
Lauren: Thank you so much, Ryan. I’d love to come back, especially with the pace of AI innovation. I’m sure we’ll have a lot more to talk about soon enough.
Part 2. Top leadership tips
Ryan: Welcome back, everyone. Again, we’re here with Lauren Creedon, and I’m excited to hear your top five tips for leadership, and especially product leadership. So, maybe let’s start with your first tip. What do you have?
Tip 1: Know your operating plan and seasonality
Lauren: My first tip is to know the operating plan and seasonality of your business and users.
We talked about this earlier, but that means knowing the assumptions in your forecast and really drawing them out of those business leaders as soon as you can. Know the markets you’re selling into so you can encourage your team to really research the competitors, price points, and expectations in those markets.
And know the seasonality, your budgeting cycles, and your usage seasonality. So you can plan launches at a time that will be most relevant and work backward from that to make sure you have enough time to take something to beta before GA.
Ryan: Yeah, that makes sense. I picked up on this in the first segment, too, that the term “seasonality” in the product world, I think, is underrepresented for a lot of people, but it’s so important, and I’m glad you brought it up.
So, definitely a good one.
Lauren: Thanks, Ryan. It’s all go to market background before I pivoted into the product, realizing after enough times launching something or trying to take something to market that wasn’t ready, just when you miss a whole year of adoption or purchase impact, it sticks with you.
So you try to get ahead of that the next year.
Tip 2: Coach your team to hit big outcomes in a quarter
Ryan: Absolutely. Absolutely. All right. What do you have for tip number two?
Lauren: So following off from that, if you know your operating plan and seasonality, and then you have this opportunity to hit a big outcome, the number two is to coach your team to hit big outcomes in a quarter.
So, as anyone knows, who’s trying to get to that next round of funding, you only have a year or two to deliver outcomes. That’s. Only four to six quarters, really, because even if you got two years, the second half of that year is looking backward at what you’ve already hit. So you need to think about front loading.
You can’t wait for something big to be like a year-long window. You need to launch something, show the adoption, and show the impact it had on your customers after that. So, by front-loading, you need to think in quarters, and a quarter might sound like a long time in software. But it’s six sprints, and if you’ve ever missed a sprint goal, six sprints isn’t a lot.
So you can use that framework. I said earlier that month zero is planning around viability risk. This is an investable idea. Let’s scope down. Month one is reducing feasibility risk to get to a working POC or beta. Month two is reducing usability risk with design and beta testing on you have a road to GA to increase adoption, and then month three is anything remaining to reduce adoption risk or improve adoption after a GA launch, and you have a working product within a quarter type of business outcome.
Ryan: Yeah, such a good format. So good. All right. How about tip number three?
Tip 3: Use end-to-end value increments
Lauren: So you mentioned this earlier. “How do you work with your engineering partners on this? ” And I touch on it a little bit, saying reducing these different types of risk. But this one is about scoping things down. So, I call this one using end-to-end value increments.
So, tip number three: use end-to-end value increments to hit outcomes. If you want to release something in a quarter, you have to get really good at scoping down that MVP. And so this concept called value increments is something me and a former colleague came up with when working on a product that we needed to ship fast.
It forces you to lay out the end-to-end workflow picture – another timeline slide – but it’s a workflow, and it’s step one/two/three. Sometimes, there are four steps in a workflow. Usually, it’s something like planning or onboarding. The second step is editing. The third step is publishing. The fourth step is measuring – people always leave out measuring and onboarding.
So, if you look at the end-to-end workflow, you add increments of the value of an end-to-end potentially releasable increment of product, or the top is your absolute need to have 1/2/3/4 steps. It’ll probably be like a B+ product. But you need to have it working end to end before you make just one step of that, like A+.
And so you’re nice to have come later, and you usually have to cut scope on them. But if you have it working end to end, you have something that’s potentially releasable, and you can weed out complexity. And so this really means leaning in with your engineering partners and figuring out where that complexity is cutting it down, releasing something that starts to solve the problem so that you don’t bloat the scope unintentionally.
Ryan: Again, great advice. Excellent. We deal with this all the time as well. And especially with meeting different client needs and you run into a variety of different scenarios, really paring it down with engineering to understand what gets you into the market is it just provides so much insight and feedback.
So, great advice. All right. Tip number four.
Tip 4: Do 1-5-50 user testing
Lauren: All right. Tip number four is about user testing. So you’ve scoped it down. You’re ready to build. You’re in build. And so often, we forget to really do successful user testing. And so I call this the 1-5-50 model. Use the 1-5-50 model for user testing.
So, 1 stands for your own internal testing. When you’re at a customer of one, people always forget about internal users. And so do it. Do it first. I know your internal team is busy, but they’re so eager to get their hands on your product.
So don’t skip that step. Do it as early as possible with the POC
As for “5” – by the customer phase, we used to call this the friendly five at Huddle. This is for your true beta. So you could be an alpha, depending on how you want to run it, or an early access program. But these “friendly five” are early adopter customers who you already have a relationship with. We’re going to be okay if they hit some bugs. They’re going to say yes to your case studies to fuel your launch plan so that you can fast-track those quotes getting approved without having to jump through hoops.
And so there, those are your friendly five. And so you can get to “friendly five” in month one or two, but don’t skip it because it takes a lot at a certain stage to manage these people in beta, especially if it’s not part of your fully launched product yet.
And you have to turn on a feature flag, and you have to walk them through it. So now you’re at 1-5. And if those customers are using it without assistance and without your support, and you don’t have to do a manual intervention to get them running, and you’re ready to grow your beta that comes to 50.
So 1-5-50. Sometimes, you’ll even want to do a whole season, a whole usage season. Like with smart cameras, we wanted to do a whole usage season at a more approachable number than going up to scale 3000 right away. So you go one, five, and then it can be 50. It could be 25. you could introduce any number of gates here, but 50 stands for when you’re testing that you’re ready to scale. It’s a valve you can release before general availability To make sure everything’s good to go before you scale it to lots and lots of customers.
The best part about the 50 stage is it’s a chance to make sure you go to market materials and positioning are resonating. It helps you test how much influx you get to support. So, if you need to change those things in support docs before a full release, don’t skip the “50” phase and go right from five to GA if you can help it.
Assessing the success of 1-5-50
Ryan: Amazing. The specificity is so good. One thing, though, that I wanted to bring up was when we’re thinking about those particular cohorts that you’re talking about, how do you qualify the right type of data to assess whether it’s working for that particular cohort?
Because I imagine I know they are different from 1 to 5 to 50 to 5,000.
Lauren: Well, you’ve got to mix qualitative and quantitative. So, the most valuable quantitative metric for me as a PM in that beta phase is task success. So that’s in the usability phase and adoption phase where you’re trying to get people to adopt it more.
There’s both task success live on an interview. You could be watching; you could be having them use your prototype and ask them to do a job. And if they can complete it without help, then they’ve figured it out. And you try to quantitatively measure how many times somebody was able to have task success on their own.
If you do a little heat map one of my product directors showed a little heat map of all the tasks they were looking to be successful with during their user interviews. And there were just like a couple of red areas, and it was glaring, “Okay, we have to invest in making that task easier.” The other one is unassisted, like totally, not even on an interview. You’ve given them access to it, and then you’re measuring the usage of the top things that were tied to value in your viability phase when you did market research, and you’re like, “People will pay for this product to generate content to post on social media.”
And so you’ve launched something that allows them to, in beta, download clips to post to social media. And you’re watching that usage to see if anyone is downloading clips. Is anyone posting it to social? And if not, then you have an option risk.
And so that’s quantitative. Qualitatively, I’d look for really spending time with customers. My favorite question to ask in a user interview is when they ask you something, “How’s it supposed to work? Is it going to have this?” Instead of just jumping in and answering, ” Oh yeah, that feature will be available later,” Don’t answer right away. Say, “What would you expect it to do?” And turn their questions back on them, and you learn so much about what they came to this product expecting it to do that can influence some of those changes you make in either your positioning or your final product bo, both qualitative and quantitative.
Ryan: Great. That’s Another good piece of advice right there. And it’s really simple and subtle because we do end up trying to defend the work that we did, right? And it’s like, “This is right,” or “We’ll get it right next time.” But really, what you are trying to determine is that expectation that’s often hard to draw out of people.
Lauren: Yeah. And sometimes they’re too nervous to say it. They think you’re the smart one who knows how to build products. And you’re sitting there just being like, “I hope I’m getting this right,” and sometimes you learn they don’t really even expect it. They were just wondering. And so you don’t have to add everything. It can be helpful, too.
Tip 5: Don’t be too smart for your own good
Ryan: That’s great. All right. Last tip. Tip number five.
Lauren: Tip number five: fail in public, and don’t be too smart for your own good. So, just help your team get comfortable failing. We talked about this earlier in the pod, but the more you work in public and fail in public and don’t worry about looking smart and having all the answers, the better your team will grow into being that way.
We see junior PM so often show up and try to like that defensive impulse. You just mentioned like to have an answer for everything or hide it when we’re off pace or trying to do something about it too fast. If, instead, we had PMs, engineers, marketing leaders, anyone showing up and saying, “This is what I don’t know. This is where we’re off pace. I measured this, and we learned this. And here’s what I’d suggest to do about it. I still could be wrong.”
That’s where the “don’t be too smart for your own good” comes in.
Early in my career, I tried to overthink everything and show up so prepared and have every “t” crossed and “i” dotted. It can come off as unapproachable or defensive, and it’s really helpful to get people comfortable in their own skin, comfortable making mistakes, and comfortable around you as a leader, too.
So my fifth one is more of a way of being than a tactic, but it’s contributed to some healthy teams.
Ryan: Awesome. Yeah, it’s a great tip for a way of being that does impact all the performance. So, excellent share. We really appreciate everything you had to share today. We’re glad you could join us, and this is an amazingly detailed podcast.
So, if you listen to it once, I suggest going back and listening to it again. There are some amazing tips in here. Thanks for bringing those to the table, Lauren. It was awesome to have you here.
Lauren: Thanks so much, Ryan. And if you’re listening and want to connect about product and go-to-market strategy, hit me up on LinkedIn.
Ryan: Very cool. All right. Thank you.