product management

Cultivate exploration:

As a leader, you want to encourage people to entertain “unreasonable ideas” and give them time to formulate their hypotheses. Demanding data to confirm or kill a hypothesis too quickly can squash the intellectual play that is necessary for creativity.

Then ruthlessly prioritize for focus:

[Force] teams to focus narrowly on the most critical technical uncertainties and [rapidly experiment for] faster feedback. The philosophy is to learn what you have gotten wrong early and then move quickly in more-promising directions.

From Gary P. Pisano writing on organizational culture for HBR. Concurrence from Paul E. McKenney, who emphasizes:

[S]tress-testing ideas early on avoids over-investing in the inevitable blind alleys.

But what kind of tests does Pisano suggest?

[do] not run experiments to validate initial ideas. Instead, […] design “killer experiments” that maximize the probability of exposing an idea’s flaws.

When people are given a menu of choices, they rarely ask:

• “what’s not on the menu?”
• “why am I being given these options and not others?”
• “do I know the menu provider’s goals?”
• “is this menu empowering for my original need, or are the choices actually a distraction?” (e.g. an overwhelmingly array of toothpastes)

From Tristan Harris, co-founder of the Center for Humane Technology. It’s the first of ten magic tricks he pointed to that technology companies use to hijack users’ minds and emotions.

Abby Sewell, with photographs by Jeff Heimsath, in The National Geographic:

Every spring, communities gather to take part in a ceremony of renewal. Working together from each side of the river, the villagers run a massive cord of rope, more than a hundred feet long and thick as a person’s thigh, across the old bridge. Soon, the worn structure will be cut loose and tumble into the gorge below. Over three days of work, prayer, and celebration, a new bridge will be woven in its place.

The Q’eswachaka bridge has been built and rebuilt continuously for five centuries.

The bridge is 120 feet long, over a gorge of considerable, but unstated, depth.

It’s said to be at -14.3811214,-71.484012.

Trains were once seen as icons of freedom. They freed riders from the dust and bumps of horse or stagecoach travel, and dramatically shortened travel times. But that view of trains as agents of freedom changed with the development of the automobile—and the way it shifted control of routes and schedules from the railroad to the driver.

This isn’t about transportation policy¹, it’s about how previously novel solutions become subject to disruption once they become the baseline against which alternatives are compared. Railroads didn’t realize they were competing against automobiles until it was too late.

Who are you competing against?

This is a revision of something I originally posted ten years ago.

Photo CC NC-ND by Schnitzel_bank.

While writing up the draft docs for Joyent’s Container Name Service I leaned heavily on the user stories and use-cases for the feature. It has me realizing that we should consider user stories to be the first draft of the user documentation.

Indeed, consider that well-written docs and user stories have similar qualities: a user, goal, and benefit, in clear language that’s accessible in small, focused chunks.

The CNS docs are now in our core documentation library, and I’m happy that we’ve updated the content management system to support deep linking to individual headings, like this one about adding CNS service tags when creating an instance with the triton CLI.

I’m thinking about this and writing now because Alexandra has joined the team and is adding short screencasts that do more to “show, don’t tell” how to use the features while providing additional context. See this screencast explaining usage with docker, assigning vanity names, and her overview of CNS’ function and purpose. She’s been digging in to the existing documentation, asking questions, and driving a lot of improvements. All that had me considering the source material and the relationship to user stories.

The following line in a post about the difference between declarative vs. imperative programming caught my attention for the way it echoes product management best practices:

[I]t’s often good not to think of how you want to accomplish a result, but instead what the component should look like in it’s new state.

Of course it does matter how you get to where you’re going, but it’s a whole lot easier if you first focus on aligning everybody on goals and where you’re going.