A framework and method for developing a Product Strategy collaboratively (Part 3)

Also some thoughts on whether or not managers should be technical

This is Part 3 in a 4-part series. Please read Parts 1 and 2 before continuing:

• Part 1: Background and overall process

• Part 2: Product Strategy purpose, framework, and async pre-work

• Part 3 (this post): In-person collaborative Product Strategy work

• Part 4: Refining and publishing the Product Strategy, next steps

---

In-person collaborative Product Strategy work

In Part 2 I discussed how (and why) we chose the Product Strategy framework that felt right for our team. I also talked about the pre-work we did to establish the current state of our Product Strategy. In this post I’d like to talk about the in-person work we did to define, for each of the Product Strategy components:

• What our ideal future state should be

• What we need to do first to get to our ideal future state

• Our hopes and fears about the future state

First, I should say that being together as a team for the first time in three years was fantastic, and definitely my highlight of 2022. At Wildbit we had annual retreats, but for ✌️reasons✌️ we obviously couldn’t get together for the past 3 years. The in-person time was universally wonderful and I am confident it will sustain another year of remote work.

But let’s get back to the strategy work. The way we structured our sessions was not necessarily conventional. I don’t know if it was the best way to do it, but we made a few intentional decisions about the structure that felt important.

First, we had the discussions together with all ~30 team members. We didn’t do the usual workshop thing where you break up into smaller groups and then report back to the larger group. This was a deliberate decision because we really wanted this to be a full team effort. It likely meant that fewer people spoke up, but it also meant everyone had all the context of our discussions at all times. I loved it. A comment from someone in customer success could spark a marketing idea from someone in engineering that got everyone excited... and that felt magical.

So, we all took live notes in a Google Doc while using the structured outline to guide our discussion (see Part 2). It was a little chaos at times, but the good kind of chaos. The kind of chaos that gets people excited about the product and our customers. I won’t be able to share too much of what the document ended up looking like, but here’s an excerpt from one section:

We could’ve done this in many different ways. We could’ve used sticky notes and affinity diagramming. We could’ve done small group work with readouts from each team. We could’ve tried to make the conversations more structured. But in the end I really like where this ended up. It was kind of exhausting (especially for the facilitators), but the energy of having everyone together in one room dreaming about the future of the product just felt so good.

Which leads me to the “what didn’t go so well” bit... We just didn’t have enough time! We mostly got to a good place with our ideal future state for each component, but we didn’t quite get to the “hopes and fears about the future state” question. I wish we had more time to discuss that because I think we would’ve gotten some really good insights out of that reflective question. That said, I believe that the outcomes we did achieve—and the way we got there—outweighed the potential drawbacks.

So what did we come out of the retreat with? We had a vision statement we all believed in. We had a long Google Doc with the raw notes from our sessions. We had enough discussion to have a common understanding of and agreement on some of the strategy components that we weren’t so sure about when we entered the sessions—such as how to think about an expansion in our target market due to the acquisition. In short, our Product Strategy was starting to come together nicely as we began to flesh out the different sections I shared in Part 2:

We also had a clear understanding of the next steps: the leads team would consolidate the document into a first draft of a coherent strategy that we can share with the team for another round of async feedback before we finalize.

That’s where we’ll continue in Part 4, the final part of the series. I’ll talk about how we refined the strategy, shared with the team and the larger Executive Leadership Team, and how we used it to come up with our broad 2023 plans. See you next week!

---

What I’m reading

David Hoang

wades into the treacherous waters of the Should managers be technical? debate, and IMO comes out safely on the other side. I really like the 3 points he makes towards the end to articulate his point of view. I won’t spoil it because it’s worth reading the whole post. There’s one other bit I wanted to comment on, though:

The key roles of managers are to set expectations, ensure the team is operating efficiently, and maximize the output of the people on your team. In order to develop people, you must have a certain level of understanding of what skills are needed for people to be successful. However, as you progress in your career, there are going to be different org structures in place where it’s relevant. If you’re a Chief Product Officer, they likely have a more broad level of understanding of other functions outside of their domain and will put leaders in place who have the depth of knowledge in those areas.

I agree with the point that as you move into a leadership role, you can’t be as involved in the technical details of the product as much as you used to. But one mistake I see leaders make is to extract themselves completely from the product. And this becomes a bigger problem, especially in larger organizations. The further away the leadership team are from customers and the product, the more difficult it becomes to create product strategies that provide real customer (and business) value. Without the context of how the product works—and more importantly, how customers use the product—you cannot have a strategy that fully takes customer value into account. You end up with strategies that are too heavily skewed towards business value. A good product strategy balances both those things.

So, leaders: Spend time with your product at a deep technical level. Download Postman and interact with the API. Ask to be invited to a few customer calls each week, and attend at least one every two weeks. Don’t lose your proximity to the heart that keeps your business alive and well.

---

This is a bleak take on Generative AI (but also kinda hard to disagree with):

We’re about to drown in a sea of pedestrian takes. An explosion of noise that will drown out any signal. Goodbye to finding original human insights or authentic connections under that pile of cruft.

---

I’m not here to defend Ticketmaster but there are some pretty interesting technical details in this article about what went down during the Taylor Swift fiasco:

Ticketmaster has provided a pretty straightforward defense of what went wrong. In a blog post that was temporarily deleted (and later edited and reposted) after Swifties swarmed it, the company said it believed that limiting the presale to “Verified Fans,” who had to receive a code ahead of time, would contain the demand to a reasonable amount. Instead, the post said, “the staggering number of bot attacks as well as fans who didn’t have invite codes drove unprecedented traffic on our site, resulting in 3.5 billion total system requests—4x our previous peak.”

If you’re into the economics of live music, the challenges for smaller artists, and how pop music has changed over time, I highly recommend this one.

---

Some stray links

• 📸 The BigPicture Photo Competition 2022 Winners have been announced.

• 📚 Great post from one of my favorite book review newsletters. Wonderful tips for how to read more books in 2023. You should subscribe to

  Read More Books
  !

• 🎙 This is a great life hack from

  Austin Kleon
  : “My favorite thing to do when I need something to listen to is to just type an artist or writer’s name into the podcasts app and see what comes up.”

• 📱This week’s useful app → Bucket — You ship features, we track their impact. “Features aren’t done when they’re deployed, but when your customers use them. Use Bucket to focus on features post-deployment and ship outcome over output.”

• 🤨 This week’s WTF link → Samsung wants Twitch streamers to buy its new oven. “It can also recommend what temperature you should cook your food at, and for how long. Oh, and livestream your food.”

• 👴 This week’s Gen X link → This book looks absolutely incredible. “Shift Happens tells the story of keyboards like no book ever before, covering 150 years from the early typewriters to the pixellated keyboards in our pockets.”

• 📈 Last week’s most clicked link → Well, it was Part 1 of the series, which would be cheating, so… the second most clicked link was 8 Quotes from “Dancing With Systems”.