Menu

Engineering maturity models and the importance of a strong foundation above all else

In his article Engineering Maturity Model Mike Fisher shares how he thinks about the importance of different team capabilities when building software organizations. Despite how some maturity models—such as the Capability Maturity Model (CMM)—have been misused in the past, Mike encourages us to look past the process and focus on the principles. Here’s the important part:

[The layers] aren’t stages in that you’re never really finished with any of them but you do need to have the ones at the base stronger and more developed than the ones further up or else you are certain to run into problems. […]

While I do think of this kind of like a maturity model, they are not stages that one achieves and moves on from. These are areas that one must keep returning to and keep investing in, always from the bottom up. Getting over your skis and investing too much in the top, which is very tempting for startups, is fraught. Too many product development teams without continued investment in the infrastructure or deployment pipeline can slow everyone down, proving Brooks’s Law. The important task for Engineering leaders is to determine when and how much investment gets made into each of these layers.

To put it another way, if the base of your infrastructure and deployment pipeline is shaky, an increased focus on product development is eventually going to bring the whole house down. Click through to the article to see Mike’s full model.

Distractions, monk productivity, and the importance of “between-time”

Sometimes the internet seems to think about the same things at the same time. Last week we were all in on meetings (see here, here, here, and here), and this week we’re all talking about distractions. Here are three excellent articles about this topic that all came across my feeds this week.

First, there is a new interview with the father of deep work, Cal Newport (NYT gift article link). He talks about context switching and “slow productivity”—and it’s really good:

I’m trying to develop this notion of productivity that’s based on, at the large time scales, the production of things you’re proud of and that have high impact, but on the small time scale, there’s periods where you’re doing very little. […] So how do you actually work with your mind and create things of value? What I’ve identified is three principles: doing fewer things, working at a natural pace, but obsessing over quality. That trio of properties better hits the sweet spot of how we’re actually wired and produces valuable meaningful work, but it’s sustainable.

Matt Reynolds has a catchy title in Wired: Easily Distracted? You Need to Think Like a Medieval Monk. It’s a fun exploration of how medieval monks were, as he calls them, “the original LinkedIn power users” who kept trying to one-up each other with how distraction-free they were living:

These kinds of stories reminded monks just how hard it was to stay focused. They weren’t expected to be concentration machines. They too would come up short every now and then. “Acknowledging that upfront is a kind of compassion,” says Kreiner. “Monks are really good at being compassionate to each other, and to how hard it was to really follow through on stuff.” Freeing ourselves from distraction is really difficult. We don’t have to feel awful about not always matching up to our lofty goals.

And finally, in a short read Mandy Brown talks about the importance of Between-time:

We live in a world full of distractions but short on breaks. The time between activities is consumed by other activities—the scrolling, swiping, tapping of managing a never-ending stream of notifications, of things coming at us that need doing. All that stuff means moments of absolutely nothing—of a gap, of an interval, of a beautiful absence—are themselves absent, missing, abolished.

If I had to find a thread through all these pieces, it would be this:

  • Not every moment needs to be filled with work that produces output. Cal Newport calls this working at a natural pace: “one with more variability in intensity than the always-on pace to which we’ve become accustomed.”
  • Everyone gets distracted. Have some grace for yourself, and others. And try to distinguish between “distractions” (filling time with stuff) and “between-time”—those real breaks that we all need but get so little of.

The one thing missing from UX today? Hope

This is a wonderful essay by Vivianne Castillo that encourages designers to hold fast to the belief that things could be better for users—and for themselves. From The one thing missing from UX today? Hope:

Today, it’s clear that many designers are feeling overwhelmed, disillusioned, and even unsafe within their organizations—and design leaders are recognizing that conversations around burnout and stress aren’t quite cutting it. I’ve found a deep sense of comfort in the words of American activist, grassroots organizer, and abolitionist Mariame Kaba: “Hope doesn’t preclude feeling sadness or frustration or anger or any other emotion that makes total sense. Hope isn’t an emotion…Hope is not optimism. Hope is a discipline… we have to practice it every single day.” 

Kaba’s quote is a reminder that the answer to feeling hopeless isn’t toxic positivity or forced optimism. The answer is to make our engagement with hope a discipline because of what’s at stake if we don’t: namely that designers will begin to believe that a better future is not possible within our lifetime.

She goes on to provide examples of how to uphold a comittment to hope in creative, human-centered ways, specifically as it relates to values of belonging, integrity, and power.

Stray Links for January 22, 2023

Every few days I post some links to things I enjoyed that don’t neatly fit into the topics I usually cover on this blog. Use it to fill your reading queue with interesting stuff.

  • The Most Ridiculous and Weird Tech Gadgets From the Last 25 Years. “The Hushme was a ‘voice mask’ intended to let you make phone calls without bothering anyone.”
  • Between-time by Mandy Brown. “We live in a world full of distractions but short on breaks. The time between activities is consumed by other activities—the scrolling, swiping, tapping of managing a never-ending stream of notifications, of things coming at us that need doing. All that stuff means moments of absolutely nothing—of a gap, of an interval, of a beautiful absence—are themselves absent, missing, abolished.”
  • Movie Trailers Keep Tweaking Well-Known Songs. The Tactic Is Working. (NYT gift article link) “As a composer, Rosen is at the forefront of the trailerization movement: He’s in demand for his ability to rework existing songs to maximize their impact in trailers for films and TV shows.”
  • All Human Systems are Enormous Trash Fires. “Once you recognize that all human systems are enormous trash fires, you stop trying to figure out how to switch to a system that isn’t an enormous trash fire, since they don’t exist. […] Eventually you even start to appreciate the beauty of it. How impressive it is that we manage to get anything done at all, given how completely trash everything is, and how on fire it is all the time.”
  • This is a beautifully-written piece about standup comedy but also about so much more. I don’t want to spoil it, except to say it starts like this: “Perhaps due to lockdown and the interruptions to normal service, but more likely due to autumnal intimations and a long dormant weakness for sentimentality, I now cherish the belief that the only flavour for which a grown-up should cultivate a taste is the bittersweet.”
  • KC Green reflects on creating the “This is Fine” meme. “When a work gets as big as this has, is it still yours?”
  • Eightify: AI Youtube Summary with GPT. A Chrome plugin that promises: “Instant AI summaries for Youtube videos using GPT. Summarize video into 8 key ideas.”
  • Can Doom Run It? An Adding Machine in Doom. “I demonstrate that it is possible to run any bounded computation in Doom, minus constraints on level size.”

The state of product and design content in 2023: “meme content wins”

These types of reports can be a bit vapid sometimes, but I am happy to say that The State of UX in 2023 by Fabricio Teixeira and Caio Braga is an extremely thoughtful, well-researched look at what’s going on in the design industry. They talk about the current economic and labor landscape, the type of skills required, how design tools are evolving, and much more. They also addresses the topic of “algorithm-driven thought leadership”, which is a topic that’s close to my heart:

When content is shorter and maximized for engagement, we often lose track of the origin, history, and context behind it: a new designer is more likely to hear about a UX law from a UX influencer on an Instagram carousel than through the actual research which brought it about.

The lack of nuance from algorithm-suggested posts undermines any value we could get from them. For a discipline known for asking “why” and for striving to understand users’ context, it’s time we become more intentional about our own information sources.

I recently did a bit of research on what type of product content “works” on LinkedIn in terms of engagement, and all I can say is that it’s really weird. If you want to get a lot of “engagement” on LinkedIn you can’t post outside links in the content (that gets down-ranked by the algorithm). For some reason long posts with one-sentence paragraphs and tons of emojis do really well. And, of course, carousels with screen shots of Twitter threads. I decided not to even try.

Things aren’t that much different on Twitter, where content is driven by long threads of fortune cookie sayings. Kyle Lambert said it well: “Meme content wins.”

I don’t want to go all old person “no one wants to read anymore” on you, but we have to admit that the current algorithmic web is optimized for extremely low attention spans. Here’s another example: there’s a specific type of Tik Tok video that’s really popular right now where users stitch random, unrelated videos together and rack up millions of views. The always-interesting Ryan Broderick wrote about it in his Garbage Day newsletter:

People on TikTok have realised that literally everybody who uses it have really short attention spans and get bored super easily. To “keep people engaged” they put 2 or more videos together with the audio being part of the “main content” while the other one or two videos are there to keep them entertained so they don’t immediately scroll down and ignore their content.

I don’t see a clear solution to all this, except to just continue to read as much longform content as we can, encourage the authors, and share that content with our peers. And also to try my best to write more like that as well.

I don’t want it sound like I think tweets or funny videos are bad or stupid. But if that’s the primary way we learn design and product principles, that is bad. Without the context of the thought process behind the decisions someone made or the framework they used, all you could ever do is copy something and apply it to a situation it almost certainly isn’t applicable to. So let’s do a little less thought-leadering and a little more explaining our “why”, is all I’m saying.

Stray Links for January 20, 2023

Every few days I post some links to things I enjoyed that don’t neatly fit into the topics I usually cover on this blog. Use it to fill your reading queue with interesting stuff!

  • The Astronomy Photographer of the Year 2022 Winners are out.
  • Did the Music Business Just Kill the Vinyl Revival? “On an aggregate level, consumers are simply not buying music. They prefer to stream it for pennies rather than purchase it for dollars.”
  • How Do Big Tech Giants Make Their Billions? I know infographics are so 2000s, but this comparison data is super interesting.
  • This week’s useful appReadow provides book recommendations powered by AI.
  • This week’s WTF LinkThe lights have been on at a Massachusetts school for over a year because no one can turn them off. “The lighting system was installed at Minnechaug Regional High School when it was built over a decade ago and was intended to save money and energy. But ever since the software that runs it failed on Aug. 24, 2021, the lights in the Springfield suburbs school have been on continuously, costing taxpayers a small fortune.”
  • This week’s Gen X linkRemembering horse_ebooks in the age of GPT3. “it’s this fear of the uncanny which i think drove the negative response to the discovery that horse_ebooks was actually no longer a bot at all. more than the disgust at feeling like you’d been played in service of a viral marketing campaign, the deeper sense that a future is coming where it won’t be possible to reliably tell the difference between bot activity and human activity lay underneath that negative reaction. and ten years later - that future is here.”

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:

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:

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.

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.