You can't just cancel 76,500 hours of meetings

Hot on the heels of yesterday’s post Meetings for an effective engineering organization, I bring you more meeting content! In You can’t just cancel 76,500 hours of meetings Becky Kane makes some good points about the context of meetings within an async culture:

Reducing meetings is just one piece of creating an async-first culture.

She gives some examples of other pieces that are harder but even more important in having a lasting impact on engagement and productivity:

Decentralizing decision-making so people don’t have to wait for permission and deliberation before acting

Delineating clear areas of responsibility so people feel individual ownership to move work forward

You can read the post for the other examples, they’re all very good! As with most of these kinds of topics it’s really valuable to think about them not in isolation, but as a system. It’s not about whether meetings are good or bad, it’s about how meetings fit into the culture and system of planning and delivery that the organization operates in.

Becky’s illustration of what “async” really means is a perfect example of this:

18 January 2023

Meetings for an effective engineering organization

It seems like the topic of meetings is on everyone’s minds again as we start the year. Will Larson has some good perspective from the engineering org viewpoint:

Some engineers develop a strong point of view that meetings are a waste of their time. There’s good reason for that perspective, as many meetings are quite bad, but it’s also a bit myopic: meetings can also be an exceptionally valuable part of a well-run organization. If you’re getting feedback that any given meeting isn’t helpful, then iterate on it, and consider pausing it for the time being. It may not be useful for your organization yet, but don’t give up on the idea of meetings. Good meetings are the heartbeat for your organization.

He goes on to recommend six core meetings for every organization to start with. The “weekly team meeting” is one I’ve become a fan of as well. Getting the entire team on a call every week has the potential for being a giant time-waster, so getting the purpose right and facilitating it tightly is essential here. For us, the purpose is:

See each other’s faces at least once a week. I wasn’t sure if the team would feel like this goal is a waste of time, but it absolutely is not. Since we’re all remote, “let’s just chat for a bit” is such a great way to start the week.
Discuss blockers/issues. This is not a status meeting where everyone goes around the room and tells us where they’re at. We have an agenda in Google Docs that anyone can add to. The goal is to bring up any issues that the team is struggling with so that we can all figure out the best way to help.
Company updates. This is also the opportunity for the leadership team to make sure the entire team has all the information and context they need to do their work effectively.

There’s one more thing about this that I highly recommend: every meeting is facilitated by a different team member. We have a schedule that we cycle through with a clear guide on what it means to facilitate—and of course, an option to opt out. This keeps the meetings interesting and everyone invested.

Previously, on meetings:

17 January 2023

Collaborative Product Strategy Development: A Case Study

When I arrived at Wildbit in 2016 as Postmark’s first product manager, my initial job was to work with the team to create a formal vision and strategy for the product. I wrote about that process in How we built a product vision and roadmap so I’m not going to spend much time on that.

The focus of this post is on how and why we redeveloped and implemented our Product Strategy after 6 years, and how we used it to create a prioritized product plan. I hope this will be helpful as a guide for teams who need to do similar work. Let’s start with a bit of background…

How it started

As a small team (<30 people) working on a bootstrapped, profitable product we were lucky that the Product Strategy we came up with for Postmark in 2016 remained remarkably consistent over the next 6 years. We made some tweaks along the way, mostly to the ideal customer journey, but the fact is that it worked, so we didn’t need to keep revisiting and pivoting over and over. That, however, changed in 2022 when Postmark was acquired by ActiveCampaign. The entire Postmark team moved over to ActiveCampaign and we are still working on the product together.

For the most part Postmark operates as its own business, but we also recognized an opportunity and responsibility to revisit and update our Product Strategy to align better with the broader ActiveCampaign vision and goals—and include plans for integrating the two products. We knew that in order to plan and deliver the right products and features to our customers, we needed an updated Product Strategy to guide us.

We are a team that loves to work collaboratively and get input from everyone, so we really wanted to create this strategy together. To do that, we broke the process up into 3 phases:

We started with some async work to clarify the framework and goals, and gather feedback from everyone about the changes we needed to make to our current strategy.
We had an in-person retreat coming up in September 2022, so we planned to discuss each element of our strategy together and come up with some rough concepts that we could refine afterwards.
Our leadership team then had the responsibility to solidify the strategy and share it back with the team and ActiveCampaign leadership for final feedback before we could call it “good for now.”

There was another part to this. We are big fans of “working in the open”, so we we felt that we had an opportunity not just to do this work as a Postmark team in isolation, but also to share our journey with anyone in the larger ActiveCampaign team who might be interested. So we created a space in Confluence where we documented our process as we went along.

I highly recommend this approach because it has the added benefit of building up “organizational memory.” If we were to come back a year from now and go “wait, why did we decide to do that?”, we will have a record not just of our decisions, but also the context and the journey that led to those decisions. This is often severely lacking in strategy work, and I believe it’s one of the main reasons why strategies seem to change so often in some organizations. If no one knows why a decision was made, the next person to come along can very easily change a strategy or a direction without having the necessary context about the work that has already been done. In short, learn to love documentation! But I digress. Let’s get back on track.

For this post, I cover each phase of our process separately:

Phase 1: Product Strategy purpose, framework, and async pre-work.
Phase 2: In-person collaborative Product Strategy work.
Phase 3: Refining and publishing the Product Strategy, next steps.

One more thing before we get going… I talk about “black hole words” in more detail below, but there is one term we had to define right upfront. Since the “Product” in Product Strategy can mean so many different things to people, we wanted to be clear on the definition right from the start. Postmark is heavily focused on product-led growth, so we clarified in our documentation that when we use the term “Product Strategy” we don’t mean only design and product experience. We mean everything that goes along with that as well: product marketing, growth marketing, sales, customer success, scaling and reliability… the whole deal.

And with that… let’s start by talking about the Product Strategy framework we chose to use, and how we collaborated asynchronously to lay a solid foundation for our in-person retreat work.

Product Strategy purpose, framework, and async pre-work

I am pretty familiar with the landscape of Product Strategy frameworks, but in preparation for our work I decided to do another deep dive into all the writing that’s out there. It is… well, a lot. Everyone approaches strategy so differently—and besides, you can’t just blindly adopt a model or framework for a team. Every team’s principles, values, and work styles are different, so whatever we used, I knew it had to fit us. I also wanted to make sure the team had at least 2 weeks to get involved in our asynchronous work, and with our September retreat fast approaching I started to get increasingly nervous.

Things finally started to come together when I decided to combine a couple of concepts into a way that made sense both for the Postmark team in isolation, as well as our work within the larger context of ActiveCampaign. The framework I proposed to the team is a combination of an adaptation of Reforge’s Product Strategy Stack, and Melissa Perri’s Product Strategy Canvas.

Here’s how I presented the framework to the team (it helps to know that ActiveCampaign’s primary brand color is blue, and Postmark’s is yellow):

Postmark Product Strategy Framework

I like the basics of the Reforge model because of how well it ties both the “blue boxes” and the “yellow boxes” together:

Each layer of the stack builds on the previous layer. Put another way, each layer is a prerequisite for the successive layer. We cannot have a company strategy without knowing our company’s mission. We cannot have product goals without knowing our product strategy. Given this relationship between the layers, Product Strategy serves a critical role—it is the connective tissue between the objectives of the company and the product delivery work of the product team.

For us this means that ActiveCampaign leadership is responsible for defining the blue boxes (which they did!), and our team is responsible for coming up with the yellow boxes. This gives us clear areas of responsibility as well as a tight connection to the goals of the larger organization.

The biggest change I made to the model was to replace the Reforge layer of Product Roadmap (“The sequence of features that implement the product strategy”) with Product Plan (“Prioritized set of problems/opportunities that implement the product strategy”). This is important because I believe this framework is too high-level for feature details and sequencing. This is especially relevant since we follow the Now/Next/Later format for roadmapping, and I was worried about the unrealistic expectations that might come with a “sequence of features”.

This framework also gave us a structured process for our work. We focused our async and in-person work on the components of the Product Strategy, and we would use our regular planning cycle (a post for another time!) to create the Product Plan.

In terms of the actual elements of the strategy, I proposed an adaptation and expansion of Melissa’s Canvas:

Product Strategy statement

I really liked where this was headed. We had a clear path towards an updated strategy. We had a few weeks to work asynchronously on documenting the current (read pre-acquisition) state of Postmark as it related to each of those Product Strategy components. We would then use our in-person retreat time to articulate the following for each of the components of the Product Strategy:

Where we are today (this was the async pre-work)
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

We created a Google Doc where we broke out those questions for each component of the strategy, and we asked the team to start filling out what they believed our current state was.

But before we could do that there was one more thing. I mentioned “black hole words” in Part 1, but we realized that each of the components of the Product Strategy will probably be interpreted very differently by each person on the team. So our Head of Marketing and I worked together to add a glossary at the top of the Google Doc with some definitions of the most important concepts that kept coming up in our discussions. We also asked the team for feedback on those definitions, and adapted quite a few based on the input we received. Here’s where we ended up:

Product Strategy. How we intend to meet our business goals through product-led growth, as driven by software, marketing, and customer success.
Go to Market (GTM) Strategy. How we identify the right problems Postmark is solving, who we’re solving for (ICP), how we position Postmark to the ICP, our key messages, and the channels we’ll use to generate awareness and encourage product adoption.
Our purpose. The reason we exist as a Postmark team.
Problem we’re Solving. The specific issue we are solving for the market.
Target Audience. The narrowest relevant set of users for our product.
Value Proposition. The specific benefits or value we provide to our audience to solve their problem.
Strategic Differentiation. The unique attributes Postmark have that make it more compelling than the leading alternatives.
Growth Strategy. The set of practices, rituals, and processes that we use to understand our audience that ultimately results in sustainable, repeatable growth for Postmark.
Monetization + Segmentation Strategy. Our business model, how we identify sub-groups in our audience and align to their needs, and how we build our product to drive growth and revenue.
Channel Strategy. The tactics we employ to reach our audience, and how we build our product to support acquisition from those sources.

And with that, we got going! The team all started adding details to the Google Doc, asked questions, debated where we really stood on each of the components, and so much more. By the time we got to the retreat we felt ready to make good use of our in-person sessions. So let’s talk about how we ran those sessions, how it went, what we learned, and what outcomes we achieved.

In-person collaborative Product Strategy work

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. 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:

Our Purpose

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:

Product Strategy

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.

Refining and publishing our Product Strategy

We came out of our retreat with a messy but comprehensive Google Doc with our raw discussion notes about each component of the Product Strategy. Our next step was to refine it, finalize it, share it, and then most importantly, use it (why is it that so many Product Strategies sit on a shelf and never get referenced?).

Once we got back from retreat, our Head of Marketing and I started collaborating on a first, cleaned-up draft of the Product Strategy (consider this a tip: product strategy isn’t just “product”, it’s everything around the product as well—that’s why we collaborated). We took each of the strategy components that we defined earlier, and consolidated our notes into a draft that we could share with the team:

Strategy doc

After sharing this we asked the team (as well as our leaders) for a final round of feedback: What works, what doesn’t, what’s missing, what’s confusing? Even though I can’t share the details of it all, you can see that there were lots of questions and comments (the yellow highlights), which helped us clarify some of the final details.

We were ready to go! No strategy is every “done”, but we felt we were at a point where we accomplished our goals for this work. We had a strategy that:

Reflected our new reality and goals as part of the larger ActiveCampaign organization.
Gave the organization and our team the strategic context we needed to move into more detailed product planning in a cohesive way.

So we published the strategy internally and shared it around. And that’s the end of it and we lived happily every after, right? Well, no, of course not. A strategy is only as good as the extent to which it influences practical, day-to-day planning and delivery. So even though we felt good (and to a big extent, relieved to be aligned on a bunch of stuff we needed to figure out), the next step was to turn the strategy into an actual plan.

We’ve been using W Planning as a team for a long time as a way to enable our empowered teams to plan collaboratively:

W Planning

I plan to write about our approach to W Planning in more detail in the future. For now, that article is an excellent reference. Since it’s a cycle we are all familiar with, and that we know works well, we used that framework for adjusting our product plans based on the new/adapted Product Strategy as well.

Phase 1: Context

The leads team got together to work on the business goals that align with the Product Strategy. We then shared this strategic context with the entire team so that everyone would be on the same page.

Phase 2: Plans

Teams took those goals and strategic context, and got together separately (product, engineering, marketing, customer success) to discuss the biggest opportunities they see for meeting those goals.

Phase 3: Integration

The leads team got together again to discuss the opportunities that the teams came up with, how it all fits together, and any trade-offs that needed to be made.

Phase 4: Buy-in

We then went back to the teams with a proposal for our main focus areas for the year. This was a particularly fun meeting because we discussed our Now/Next/Later roadmap together, dragged things around, and got alignment on the most important opportunities we wanted to address next. (We use Productboard for our planning and roadmapping—I’ve written about our usage of Productboard before but a lot has changed since then so this should probably also be a topic for an upcoming post.)

Now Next Later

After this the teams started working on their project plans (I wrote about the project plan template we use here). And just like that, we were off to the races with detailed planning and delivery on customer and business value.

How it’s ending

The thing I liked most about this process is the reason for the title I chose for this post: Collaborative Product Strategy. This wasn’t a situation where our leaders sat in a room and came up with stuff. Via each team member we stayed close to our customers and our business throughout the process. And we didn’t do this because it feels better (although it does!). We believe that we get better outcomes when decisions are made by the people who are closest to the data (i.e. customer needs, industry knowledge, etc.). That means that if a Product Strategy is not set in a way that ensures you have all the relevant data, it is more likely to fail. So I guess if I have any advice about Product Strategy, it would come down to this: don’t do it alone.

There’s probably a lot more to say, but I’m going to end it here. I really hope this has been helpful. I’d also love to know what questions/feedback you may have on this process! Please let me know via Linkedin, or on Mastodon.

16 January 2023

How to manage work that is always “in progress”

I enjoyed this post by Yuhki Yamashita (CPO at Figma) about how design is always “Work in Progress,” and how to deal with that:

Our work never feels done because it isn’t. Our collaborators jump in and out of files, leaving feedback and iterating on designs while we’re creating them. Many of us can ship whenever, so it’s hard to know when new designs are actually ready. It’s the chaotic reality of modern product design and development.

He gives some really good recommendations for how to work in this type of world where nothing is ever quite “done”. The post also introduced me to the concept of flashtags, which I quite like. It comes from Hubspot (See FlashTags: A Simple Hack For Conveying Context Without Confusion), and it’s a way for leaders to indicate how strongly they feel about the feedback they’re giving:

#fyi means there’s no hill to die on.

#suggestion means they’ve seen the hill but don’t feel strongly enough to commit the energy to climb it. Take it or leave it.

#recommendation means the hill was climbed. They thought about dying on it, but walked back down.

And finally, #plea means that they do, in fact, want to die on the hill. So if you see this flashtag, you better make sure it’s prioritized!

And finally, speaking of Yuhki… I am not really a podcast person, but I really enjoyed his recent interview on Lenny’s Podcast: An inside look at how Figma builds product.

16 January 2023

“Screen time” is dumb—5 questions for educational/technology expert and advocate Richard Culatta

This is an interesting interview with Richard Culatta, author of Digital for Good: Raising Kids to Thrive in an Online World. They discuss how to help kids bridge the gap between physical and digital spaces, how to model good technology behavior, and more. This is such a good point:

By focusing on screen time we miss the far more important concept that we should be teaching our kids; screen value. Some digital activities are just not a good use of a kid’s time (eg. playing a repetitive, luck-based game) while others provide much greater value (eg. editing a movie, creative writing, FaceTiming with a grandparent, etc.) And context is important to consider too. Digital activities that are appropriate on a long car-ride will likely be different than those on a beautiful spring day when friends are around, or the day before a large school project is due.

I’m going to go out on a limb here and say that is something that not only kids need to learn. We can all benefit from this lesson:

The most important lesson we can teach young kids is to recognize that some digital activities provide more value at some times than others. This means evaluating each digital activity on its own merit based on the circumstances.

We should probably also remember that controlling children’s behavior with screen time leads to more screen time:

Researchers investigated the impact of parenting practices on the amount of time young children spend in front of screens. They found a majority of parents use screen time to control behavior, especially on weekends. This results in children spending an average of 20 minutes more a day on weekends in front of a screen. Researchers say this is likely because using it as a reward or punishment heightens a child’s attraction to the activity.

14 January 2023

The Death of Hybrid Work Is Greatly Exaggerated

I agree with Bruce Daisley in The Death of Hybrid Work Is Greatly Exaggerated:

The focus for organisations in 2023 shouldn’t be on mandating a return to the office, but on working out how to build strong cultures in a new, sustainable way. Some of that is about optimising the time that teams spend together, curating rather leaving it to chance. If we’re to get the best out of work culture then we all need to accept that this is the moment to reinvent the construction of it.

It’s a common criticism of remote work that it’s more difficult to collaborate remotely. But I think this is the conventional wisdom only because we try to recreate the office experience for remote work. Since offices rely on synchronous interactions, we use the same lens to try to make remote work effective, and that’s just not going to work.

If we optimize for asynchronous communication instead—which is what remote work is so good at—collaboration can be extremely effective. Perhaps even more effective than office collaboration, because everyone can provide thoughtful responses on whatever topic they are discussing on their own time. As Brian de Haaff points out in Remote Workers Are Outperforming Office Workers—Here’s Why:

Without being able to lean on physical proximity, remote workers must reach out to one another frequently and with purpose. This leads to stronger collaboration and camaraderie.

As counterintuitive as it sounds, this has been my experience as well. As long as we shift the way we think about collaboration away from the office mentality, and use the right tools, I don’t think remote collaboration is less effective than in-person work at all.

13 January 2023

How Brasília’s urban design affects citizen behavior during political violence

My friend Allan sent me an article about the city of Brasília, and how its architecture affected the recent insurrection (Ryan wrote the best overview about what happened that I’ve seen). I have long been fascinated with Brasília, every since I researched it for a product management article called Usable yet Useless: Why Every Business Needs Product Discovery:

A “shiny citadel” from far away, as The Guardian once wrote, up close Brasília has “degraded into a violent, crime-ridden sprawl of cacophonous traffic jams. The real Brazil has spilled into its utopian vision.”

This problem echoes across today’s web landscape as well, where the needs of ordinary users spill constantly into designers’ utopian vision.

So I read In Brasília, Modernist Architecture Met Political Violence with great interest:

Brasília’s so-called Monumental Axis, or Eixo Monumental, isn’t a walkable touristic path dotted by free museums. Instead, it is an otherworldly landscape of red earth, open grass and enormous roadways, an anti-pedestrian landscape best viewed from the air. So vast are its voids that the sheer scale of the space may have helped temper the energies of the crowds.

The city’s design had specific consequences for the political unrest:

More than 60 years later, Brasília’s real-world shortcomings are well known: Its population far outgrew what its designers imagined, with most residents living in satellite developments that sprawl far from Costa’s planned central district. Many politicians commute via plane, making the city more a symbolic site than a place where one finds gatherings of politicians. President Lula was not in Brasília at the time of the riot, nor were legislators of Brazil’s National Congress, which is in recess: The protesters attacked mostly empty buildings.

This is a really interesting look at how urban design affects the behavior of citizens.

13 January 2023

Letting books talk to each other

I love this bit from Austin Kleon’s Letting books talk to each other:

If you read books on different topics and different genres and different formats at the same time, your brain can’t help but find weird connections between them.

This is one of my favorite things—not just with books, but with articles too. It’s such a good feeling when your brain makes those connections. I’ll add that I think this is what makes blogs like Kottke so effective and compelling. When you are able to find and share the connections between things, you have something special going on.

12 January 2023

Things they didn't teach you about Software Engineering

Good post by Vadim Kravcenko on Things they didn’t teach you about Software Engineering:

Although it may sound surprising, the primary focus of a software engineer’s job is not writing code but rather creating value through the use of software that was written. […] Elegant code, best practices, smart solutions, design patterns — these are done for the sake of your fellow software engineers who will work on the codebase after you rather than helping you fulfill the purpose of bringing value.

And speaking of meetings:

It’s all interconnected, and the meetings are where the information is shared. As a software engineer, you are responsible for some part of this information sharing, so it would be irresponsible to hinder it. You might not like it, but the information must be shared for the system to remain efficient.

12 January 2023

When meetings are outlawed, only outlaws will hold meetings

Here is a good articulation of why I wasn’t as enthusiastic about the Shopify meeting cancelation thing as most everyone else. Something felt… off? Here’s the Raw Signal team in When meetings are outlawed, only outlaws will hold meetings:

But the long-term fix for bad meetings isn’t no meetings, it’s competence. If you run a bad meeting, you need to fix the meeting or cancel it. But if you run a company full of bad meetings that need annual reboots, you need to fix your management team. Because while collaboration, alignment, decision making, and unit cohesion can all happen outside of meetings, well-run meetings are a very useful and effective place to accomplish those things. Taking that tool out of your management toolbox might be prudent if you don’t trust your managers to use it without hurting themselves or others. But it would be better if they were competent.

Also this:

Running an effective meeting means being opinionated about what it is and isn’t for, and fierce about not wasting the time of your invitees.

→ Context: Shopify CEO Tobi Lutke Tells Employees To Just Say No to Meetings.