products
Eating your own dog food
To anticipate all the uses and abuses
To read things that are not yet on the page
To love deeply a world of things
Product owner vs. product manager
Ensuring Excellence
The other way to build a massive tech company - doing it slowly
Framing vs. Shaping
The Nature of Product
An Article by Marty CaganToo many product managers and product designers want to spend all their time in problem discovery, and not get their hands dirty in solution discovery – the whole nonsense of “product managers are responsible for the what and not the how.”
Why Scrum is killing your product
An Article by Henry LathamWhat happens to user experience in a minimum viable product?
An Article by Ryan Singer"Feature complexity is like surface area and quality of execution is like height. I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I'm committing to a baseline of effort on the user experience."
There’s a distinction to make: The set of features you choose to build is one thing. The level you choose to execute at is another. You can decide whether or not to include a feature like ‘reset password’. But if you decide to do it, you should live up to a basic standard of execution on the experience side.
Features can be different sizes with more or less complexity, but quality of experience should be constant across all features. That constant quality of experience is what gives your customers trust. It demonstrates to them that whatever you build, you build well.
Research, empathy, simplicity, speed
An Article by Matthew StrömAs 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.
August short No. 2: Glass
An Article by Riccardo MoriGlass looks and feels perfectly tailored to my photo sharing needs and expectations. For me it’s even better than pre-Facebook Instagram in the sense that it pushes me to select and share what I think are good photos (same as it happens with Flickr), rather than making me obsess with getting ‘the Instagram shot’ at all costs every day or multiple times in a day. It doesn’t cheapen photography like Instagram has done for years.
That’s why I hope Glass’s founders/developers will resist feature creep. Resist user objections like: I don’t think Glass is offering that much for the subscription price they’re asking. There are a lot of people who will gladly pay for having a cleaner, simpler, focused experience.
Apps Getting Worse
An Article by Tim BrayToo often, a popular consumer app unexpectedly gets worse: Some combination of harder to use, missing features, and slower. At a time in history where software is significantly eating the world, this is nonsensical. It’s also damaging to the lives of the people who depend on these products.
...Maybe we ought to start promoting PMs who are willing to stand pat for an occasional release or three. Maybe we ought to fire all the consumer-product PMs. Maybe we ought to start including realistic customer-retraining-cost estimates in our product planning process.
We need to stop breaking the software people use. Everyone deserves better.
The Hot Potato Process
An Article by Dan MallThe big misconception I’ve seen designers and developers often fall victim to is believing that handoff goes one way. Designers hand off comps to developers and think their work is done. That puts a lot of pressure on the designer to get everything perfect in one pass.
Instead, great collaboration follows what Brad Frost and I call “The Hot Potato Process,” where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle.
Signing party
An ArticleSince the Macintosh team were artists, it was only appropriate that we sign our work. Steve came up with the awesome idea of having each team member's signature engraved on the hard tool that molded the plastic case, so our signatures would appear inside the case of every Mac that rolled off the production line. Most customers would never see them, since you needed a special tool to look inside, but we would take pride in knowing that our names were in there, even if no one else knew.
Software that nobody wants
An Article by Gandalf HudlowFinding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.
What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
- Not wanted - Company specified a solution to a problem that customers don't actually have
- No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
- Incorrect Packaging - Customers need a website, but the company created an iOS app instead
- Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
Don't Serve Burnt Pizza
A Fragment by Jiaona ZhangSay you’re trying to test whether people like pizza. If you serve them burnt pizza, you’re not getting feedback on whether they like pizza. You only know that they don’t like burnt pizza. Similarly, when you’re only relying on the MVP, the fastest and cheapest functional prototype, you risk not actually testing your product, but rather a poor or flawed version of it.
Broken world thinking
A Fragment by Amanda MenkingConsider, for example, how “broken world thinking” can benefit product design. What if the person (or team) who invented a new technology collaborated with the person (or team) who would one day repair the same technology? What if the innovation stakeholders and the infrastructure stakeholders collaborated closely with the end users? What if every new product designed by a technology company was designed in such as way as to factor in what happens to the product after planned obsolescence?
Putting Thought Into Things
An Essay by Oliver ReichensteinBuilding structure requires serious listening, serious reflection, and serious imagination. All this requires experience, and no matter how experienced you are, it costs you. We spend our time and nerves to save users their time and nerves. Well-designed things give us the invaluable present of time. Well-designed products do not just save us time, they make us enjoy the time we spend with them. They make us feel that someone has been thinking about us, that a nice person took care of the little things for us. This is mainly why we perceive well-designed things as more beautiful the longer we use them, and the more used they become.
On the "Building" of Software and Websites
I’m beginning to suspect that software, and more conspicuously the Web, is fundamentally the wrong shape for the archetype of the construction project.
You are agreeing to make a Thing
When you sign the contract for the construction project, you are agreeing to make a Thing—app, website, whatever. And you will have agreed to deliver this Thing on a certain date, also known as a deadline. From this point forward, the goals of shipping the Thing on time and actually solving the client’s problem will be in competition with each other.
The Thing-deadline calculus
Now, I understand deadlines. I understand that the plane will take off whether or not I’m on it, or the importance of beating the holiday retail rush, or that "the show must go on". It is perfectly clear to me how people use timekeeping technology to coordinate social activity. It’s actually quite remarkable when you step back and look at it. But, over the years, I have observed that there is a difference between those examples and the ones around the delivery of Things, which tend to be completely arbitrary. When you wrap an arbitrarily complex endeavor up in a neat launch date, the goal seems to be more about coercing the people beneath you to absorb the overhead of all the details you left out—that or sweating it yourself. As a tool for coordinating human activity, I have come to believe that the Thing-deadline calculus is, considering more sophisticated alternatives, unnecessarily crude.
Trees and graphs
A tree is a kind of graph, but a graph can be considerably more complex than a tree.
I have reason to believe, which for brevity’s sake I will treat elsewhere, that the most complex class of processes and structures we humans can consciously prescribe, reduces mathematically to a tree. A tree has a top, bottom, left and right. Its branches fan out from the trunk and they don’t intersect with one another. They are discrete, contiguous, identifiable objects which persist across time. Trees are Things.
Software and websites, however, reduce to arbitrarily more complex structures: they are graphs. A graph has no meaningful orientation whatsoever. No sequence, no obvious start or end—at least none that we can intuit. It is better considered not as one Thing, but as a federation of Things, like the brain or a fungus network, or perhaps a composite artifact left behind from an ongoing process, like an ant colony or human city.
Content as value
The most important consideration for any software or web excursion is content: the content of the text and other communicative media, as well as the content of the code that executes the business processes. The ability to tick off a page or piece of functionality as being done only produces a nominal successful result; the careful crafting of what one of these objects says produces a real one.