Questions to answer before adopting a new technology

Kellan Elliott-McCrea has an excellent list of questions a team should answer before they decide to adopt a new technology in their software development process. For example:

If this new tech is a replacement for something we currently do, are we committed to moving everything to this new technology in the future? Or are we proliferating multiple solutions to the same problem? (aka “Will this solution kill and eat the solution that it replaces?”)

As he mentions in the post, these questions are not subtle… but I think they’re absolutely essential. It reminds me a little bit of Marty Cagan’s Product Opportunity Assessment questions.

The human-centered dilemma

Design is only as “human-centered” as the business model allows.

— Erika Hall, Thinking in Triplicate.

Users as friends, and other product principles from WeChat’s creator

In Four Key Product Principles from WeChat’s Creator, Connie Chan outlines how Allen Zhang, the Chinese programmer known for creating WeChat and Foxmail, thinks about Product:

The backbone of Allen’s product philosophy is thinking about users as his friends. This means designing products with sincere best intentions for the users and putting their interests above all others — even company stakeholders. For Zhang, the importance of always putting the user first is very simple: “Only when we treat users with genuine empathy will our products be used for a longer time.” What this means to Zhang is that product design should not be reduced to “processes” that can be continuously optimized by data-driven teams. He believes there is an amount of whimsical inspiration that process optimization cannot solve for.

The whole profile is worth reading. Zhang is inspiring, and we need more product thinking like this.

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


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 123