Menu

From output-based to outcome-based product planning

Cause & Effect and Product Risk” is a good good post by
Scott Sehlhorst on the importance of moving to an outcome-based approach when evaluating and planning product features. He also discussed how to use Impact Mapping to do it:

When we collaborate to develop a shared understanding that explicitly connects “building X” with “realizing benefit Y” we address the first problem. Impact maps are great for this, because in the process of creating the connections, we intentionally challenge those connections and explore others; creating a better plan, shifting to a bigger goal. All while providing deep context throughout the teams, increasing likelihood of successful delivery and effective stakeholder management.

Product management doesn’t require in-person collaboration to be effective

Remote product management is something I’ve written about before, so I read Julie Caprio’s Four Keys to Successful Remote Product Management with interest. In general I agree with the advice she gives in the article, but there is one section that I wanted to respond to briefly:

Product management, on the other hand, was more of a struggle. A PM needs to set strategy and come up with a vision for the product. Without the potential for spontaneous in-person conversation and even inspiration, this part of the job gets a bit harder. Creating a vision for a product is a collaborative effort involving several stakeholders; when the team is distributed, it’s more difficult to align on goals, tasks, and project ownership.

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.

Limiting the downside of negative impacts by focusing on product resiliency

In The Misunderstood World of Product Growth Joe Van Os makes some great points about the importance of focusing on making your product resilient to negative impacts:

Since it is impossible to forecast when positive opportunities will appear, it is important to be in a position to take full advantage of them when they do. If a product team is in fire-fighting mode (dealing with the fallout of negative circumstances), opportunities with plenty of upside may be missed.

Limiting downside (technical debt, red-tape, etc) allows a product or business to quickly recover from negative impacts, as the negative impact will be contained. It is building a tough product.

The Rise of Product Ops

Product ops builds a foundation for excellence by reinforcing product strategy with metrics, infrastructure, business processes, best practices, budgeting, and reporting.

— Shaun Juncal, The Rise of Product Ops: Supporting Product Excellence at Scale

Good Strategy/Bad Strategy

I’m adding Good Strategy/Bad Strategy to my reading list, based on some of the quotes in this review:

Every organization faces a situation where the full complexity and ambiguity of the situation is daunting. An important duty of any leader is to absorb a large part of that complexity and ambiguity, passing on to the organization a simpler problem — one that is solvable. Many leaders fail badly at this responsibility, announcing ambitious goals without resolving a good chunk of ambiguity about the specific obstacles to be overcome. To take responsibility is more than a willingness to accept the blame. It is setting proximate objectives and handing the organization a problem it can actually solve.

On making the web with a text editor and a few hours

This essay about the building blocks of the web by Rachel Andrew is really important. From HTML, CSS and our vanishing industry entry points:

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

The healthy engineering culture at Postlight

Web agency Postlight wrote about their engineering culture, and what a breath of fresh air it is to read this list in the midst of the current “hustle til you drop” culture:

The positivity of our internal communication fosters a team that is warm and easy to engage with for our clients. Our clients are shocked by how easy it is to communicate with our engineers. No knee-jerk reactions. Just a friendly, two-way, conversation with professionals.

Or, as we phrase it in our Wildbit values, “As a team, we support each other to do the work of our lives.”

The product manager’s battle between ego and customers

It’s a bit of an uneven piece, but Peter Krmpotic’s What’s the Secret to Becoming a Great Product Manager? makes some good points about ego vs. customer focus:

The ultimate goal for product managers and product leaders is to instinctively focus on the customer and not their own egos. This is hard since it is natural to be self-centered and unnatural to be customer-centric.

In Scott Belsky’s recently published book “The Messy Middle”, he highlights how we are hardwired to prefer short-term rewards, because delayed gratification causes anxiety and discomfort. Thus, I think the main career-long objective for product managers is to reprogram themselves over time from being self-centric to customer-centric, to get the urge of acting on their own ideas out of their system. Or as Belsky puts it, “to hack their reward system”.

More

  1. 1
  2. ...
  3. 48
  4. 49
  5. 50
  6. 51
  7. 52
  8. ...
  9. 201