Design is only as “human-centered” as the business model allows.
— Erika Hall, Thinking in Triplicate.
Design is only as “human-centered” as the business model allows.
— Erika Hall, Thinking in Triplicate.
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.
“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.
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.
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.
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
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.
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.