Menu

Posts tagged “prioritization”

Feature/Product Fit

I like this framing by Casey Winters on how to evaluate Feature/Product Fit when you release something new:

Feature/Product Fit has a third requirement that is a bit different: the feature has to improve retention, engagement, and/or monetization for the core product. This last part can be a bit confusing for product teams to understand. Not only do the products they are building need to be used regularly and attract their own usage to be successful, they also need to make the whole of the product experience better.

Any new feature is part of the larger product system, and our success metrics should take that into account.

Why meeting overload happens, and what to do about it

Anne Helen Petersen brings some much-needed clarity to the meeting overload debate in The Root of Over-Meeting Culture. It’s worth reading this one in full because she takes her time to lay out the argument logically, but a few of things especially stood out to me.

When their team was fully in the office, managing probably felt straightforward. Most people managed by, well, looking and walking around. That was the heart of it. Now, figuring out what your team is doing, and how they feel about doing it, it’s a lot more work. So managers not only feel like they’re doing more work — and less productive themselves, as workers — but they also feel like they’re doing a worse job, and have less insight into what their reports are doing.

This is a good point that I don’t see talked about much. One of the reasons that RTO policies have become so prevalent is the lack of visibility that managers feel about the work their teams are doing. There are way better solutions to this problem than forcing a return to the office (regular async updates, clear priorities, etc.), but that seems to be the default approach to deal with what is essentially a communication problem, not a presence problem.

More talk about prioritization = more manager confidence (that their reports are doing the things that matter most) and more employee confidence (that they’re doing what they should be doing). It’s difficult to understate just how powerful this sort of clarity can be.

Related to the previous quote, +1 to this! No one on the team should be wondering if they’re working on the right things, and what they should be doing next. This is, in my opinion, the most important job of the 1:1 meeting, and why that meeting has to be (at least) weekly.

I have all the reservations about AI that other smart people do, but one of its real potentials is summarizing meetings in a way that makes people feel like they understood what happened and whether or not their input is needed after the fact without having to attend the actual meeting.

Another big +1 to this. Gong does this incredibly well by summarizing sales calls, pulling out action items, providing searchable transcripts and call insights, and more.

There are some pretty wild stats in the post about how meeting time has increased 252% since 2020. Some of that is necessary because of the shift to remote work, but not all of it. We somehow still view meetings as the default solution to figuring out what’s going on in an organization. I wrote Good / Bad Remote Worker before the pandemic, but I think this principle is more important than ever:

A good remote worker always thinks about collaboration through the lens of asynchronous communication. Remote work naturally creates great environments for deep, focused work, so it makes sense to optimize for asynchronous communication. This lets everyone get involved when it works best for them — and when they are ready to give something their full attention.

A bad remote worker tries to recreate an open office environment through too many meetings and other forms of synchronous communication. Meetings aren’t inherently bad. But unnecessary meetings and synchronous feedback sessions undermine one of the most significant benefits of remote work and should be used sparingly.

How To Ship Fast

This is a highly opinionated piece (nothing wrong with that!) and I think there’s some nuance needed, but in general I like these principles from How To Ship Fast. This one is definitely a hot take, but in a dream world where everything is perfect I would agree:

Time spent on prioritization is the canary in the coal mine for not being close enough to your customers. The discrete task of prioritization should take almost no time. Only work on Important things. Sort those Important things into “Do now” and “Do next”. If you are only working on Important things, the order does not matter too much (and don’t spend time debating it). If what’s Important is not obvious you are not close enough to your customers.

Ask Teresa: My Leaders Still Want Roadmaps with Timelines—What Should I Do?

Good points here from Teresa Torres about deadline-driven development, especially the need to take change management slowly:

If your stakeholders are insisting you use date-based roadmaps, I wouldn’t engage in the ideological war about deadlines and predictable work. Instead, start with a feature-based roadmap. Give your stakeholders what they are asking for, and over time, you can introduce opportunities and outcomes.

Product quality as differentiator

I fully agree with Chris Coyier’s main point in Other People’s Busted Software is an Opportunity:

If you make software that does work reliably, you’ve got a leg up. Even if your customers don’t tell you “I like your software because it always works”, they’ll feel it and make choices around knowing it.

It feels like so many teams prioritize “innovation” over quality, so we end up getting stuck with products that have an overwhelming number of features but they all barely work—or the whole thing is slow and cumbersome. At some point we seem to have forgotten that product quality is not optional, and that it should be built in from the start.

Not only that, but in a “project” mindset teams just continue to move on to the next feature without taking the time to learn and improve what they shipped, as Marty Cagan points out in From Projects to Products:

Most efforts lose all hope of providing real value, and just try to get something shipped. Then as soon as they do finally ship, it’s not like they can iterate to improve the product. Instead, the people usually scatter off to their next assignments; nobody owning the outcome, and any important learnings from the effort likely lost.

This seems almost silly to point out, but a feature is not going to help your business if (1) it doesn’t add value and/or (2) it doesn’t work well. And yet somehow lots of teams put validation and quality on the backburner while they rush to get more features out. So Chris is right in his post: focusing on product quality is a huge differentiator in today’s software market.

Life beyond OKRs: Tools for goal-setting

Ok, here’s the thing. I didn’t share this talk I’m doing on Thursday when it was announced because as much as I tried, I just didn’t feel like the story was coming together. Writing this talk was much harder than some others that I’ve done, but I think I finally got there last night. So with only a few hours to spare, here you go…

In Life beyond OKRs: Tools for goal-setting I’m going to talk about our team’s foundation (principles & values), how we set goals, and how we plan and execute. If that’s your thing, come join us!

Managing feature requests from stakeholders

It might be controversial, but I tend to agree with Kax Uson point about managing feature requests from stakeholders:

I have learned that it’s perfectly alright for stakeholders to have solution requests. And to expect them to bring problems to us is unrealistic.

The post gives some good advice on how to translate solution requests into problems/opportunities that teams can solve:

Speak the language they speak. Talk about the benefits and impact of their requests. If you do build the feature they’re asking for, what value would it provide for the customers/users and the company? Speak in outcomes.

Evaluating AI product opportunities by plotting them on a “Survival Curve”

Aniket Deosthali (Head of Product for Conversational Commerce at Walmart) provides a great framework for evaluating AI product opportunities in How to Build AI Products People Want:

The most efficient way to evaluate AI opportunities and unlock the advantages of AI is by using the Consideration x Context framework. Let’s start with some baseline definitions.

Y-Axis = Consideration: The amount of effort required to make a decision.

The more thought you put into a decision, the higher consideration it is. For example, choosing a dish detergent is “low consideration” for most shoppers, compared to buying a car which is “high consideration.” Consideration can be represented as a function of the number of compelling alternatives and the stakes - users’ tolerance for errors, for example.

X-Axis = Context: The volume of abstract concepts AI needs to know. 

Context refers to how many abstract concepts a model needs to know in order to provide a useful response. Does it only need to understand a small batch of data points (like a product catalog), or does it need to understand the entire internet (like ChatGPT)?

He goes on to explain how to plot different solutions on a “Survival Curve.” If you work on AI products this is one of the rare actually helpful articles for PMs in the area of AI and LLMs.

Experimentation in the real world: Southwest Airlines

The post 7 innovations that Southwest is testing to improve its crucial turn times is a great real-world example of experimentation in product (make sure your ad blockers are charged for this one, it’s published on The Points Guy…).

Zach Griff goes over several ideas Southwest Airlines are trying to improve the time between when a flight arrives and leaves again. For instance, for when you’re queuing on the jet bridge:

The first is the installation of Bluetooth speakers in the jet bridge, which play (royalty-free) disco, electronic dance music, hip-hop and kids music during boarding and deplaning. Listening to music at a high beats-per-minute rate is scientifically proven to get people moving faster and more efficiently, according to McCartan, which is exactly what Southwest wants during one of the most critical phases of the turn.

There are lots of learnings for PMs sprinkled throughout the post.

How much product data is enough?

I really like this list of heuristics by Itamar Gilad for how much data you should have before launching product features/improvements:

  • Never launch anything solely based on opinions.
  • It’s ok to release minor tweaks based on assessment.
  • Having supporting data (without testing) is enough to launch only very small, low-risk, easy-to-revert changes.
  • Everything else should be validated through tests and experiments. However there are various levels of testing to choose from with different associated costs and confidence levels.  
  • How much validation you need depends on: a) the cost of building the idea in full, b) how risky it is, and c) your risk tolerance. 

Conf Meter Quads scaled

It’s also the first time I’ve come across his confidence calculator, which looks like a really useful tool (email-gated, though…).