Forget 10×. With a focus on outcomes and an eye towards the border between net-positive and net-negative work, any team can push their productivity beyond their previous limits.
...If you can perform one task better than most people, you might be a 10× designer or developer or product manager (or whatever you are). But if your team can find small ways to make many of their tasks net-positive, 10× is just the start.
In 1969, the people in charge of Apollo 11 trusted a 23-year-old engineer in a back room of mission control to make one of the most consequential decisions of this decade-defining mission. And they did so in seconds, without deliberating or debating.
Next time you’re faced with a decision, ask yourself: how can this decision be made on the lowest level? Have you given your team the authority to decide? If you haven’t, why not? If they’re not able to make good decisions, you’ve missed an opportunity to be a leader. Empower, enable, and entrust them. Take it from NASA: the ability to delegate quickly and decisively was the key to landing men on the moon.
As Nosrat provides a simple list of essential ingredients for any great meal, can we describe a simple list of essential components for digital products?
Here are four elements that I believe are the foundation of great digital products: Research, Empathy, Simplicity and Speed.
Recently I’ve had a few opportunities to use code to create design. In two of my bigger projects at The Wall Street Journal, writing code has led to new ideas. Problems that typically plague early designs — e.g. “how does this look with real content?” — are easy to solve. By exploring visual ideas directly in code, I’ve started to see the amazing potential of code as a design tool.
When I was a product designer, people would ask what I did for a living, and sometimes I’d answer “I draw pictures of websites.”
Sure, I could just say “I design websites.” That’s true. The end result of my work is (hopefully) that a website looks better, works better, or results in better outcomes.
But most of my day isn’t spent looking at the website, or working on the code of the website, or manipulating the website directly in some way. It’s spent in Figma or Sketch, drawing pictures of how I think the website should look and work.
Through some kind of alchemy, the pictures I draw have an impact on the finished website. But they’re not all the same.
This is a very short book about copying. Its contents, unless otherwise noted, are licensed under CC-BY SA 4.0 (more on that in a bit). You can download, copy, remix, excerpt, change, and repost it however you see fit.
Prescriptive feedback limits creative collaboration. I’ve seen it time and time again, but I’ve struggled to articulate the exact reasons and their remedies. Recently, though, I got some insight from an unusual source: a game of chess.
When I wrote about the virtues of empowered product teams, I was referring to what I’ll continue to call here as product teams. Specifically, they are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve.
In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.
However, in a feature team, you still (hopefully) have a designer to ensure usability, and you have engineers to ensure feasibility, but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.
If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong.
Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question.
And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question.