In The Value of Inconvenient Design Jesse Weaver discusses the role of user friction in design — the things that slow us down from getting a task done — and how the goal is not to remove all friction from our product flows:

The friction of the checkout process provides a check against impulse purchases and overspending. In a world where many people struggle to manage their money, these small barriers can be critical to maintaining financial balance. While the market would dictate that it’s not Amazon’s job to help its customers control their spending, lowering the barrier to impulse purchases could have a net negative effect on the value people get from Amazon’s service. The Dash button, for example, eliminates so much friction that customers may not even know how much they’re spending until after they’ve completed a purchase. In light of this, Amazon Dash was recently deemed illegal in Germany for violating consumer protection laws.

If you’re interested in the topic of “frictionless design”, here is some related reading. Clive Thompson digs into software that aims to add friction to our lives in his Wired essay We Need Software to Help Us Slow Down, Not Speed Up:

It’s certainly possible to slow our software, and thereby ourselves. But it’ll happen only when we become too unsettled by the speed of our journey.

Here is Chris Palmieri in A Practice of Ethics:

But some friction is borne of respect, when we present information about the choices available to users and help them make better decisions. An emailed invoice could remind a customer they were paying for a service they no longer use. A checkbox could assure a user of their current content privacy settings before posting a sensitive photo. Recognition of a past purchase can save a customer the hassle of having to return a book they already have, or confirm that they are re-buying exactly the same shampoo.

And Andrew Grimes in Meta-Moments: Thoughtfulness by Design:

Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.

In short, not all friction is bad…

Marcus Buckingham and Ashley Goodall discuss some fascinating research about how people learn in their essay The Feedback Fallacy:

What findings such as these show us is, first, that learning happens when we see how we might do something better by adding some new nuance or expansion to our own understanding. Learning rests on our grasp of what we’re doing well, not on what we’re doing poorly, and certainly not on someone else’s sense of what we’re doing poorly. And second, that we learn most when someone else pays attention to what’s working within us and asks us to cultivate it intelligently.

As a parent it’s natural to see the elements of “positive parenting” in this research. We (generally) don’t have to deal with tantrums at work, but it still makes sense people would be more motivated by this approach than by reminders of what they’re doing wrong. Something to keep in mind as we work with our teams.

My friend and colleague Garrett Dimon wrote about his experiences building and selling a product in his post Hindsight. He gives some advice based on what he learned. You might not agree with everything, but I think his perspective is really interesting and worth checking out. For example, on the balance between building product and doing marketing:

I don’t want to build an operational system to grow a business and then spend no time on the product. I want to design a company to build the product and serve customers. That’s not to say that there shouldn’t be some type of marketing that will need to be done, but I’d rather find ways where marketing is a by-product of the software rather than a separate activity. Checking analytics and numbers eventually becomes relevant for a business, but it’s a spectrum. I want to check the numbers to make sure the business is healthy, but I don’t want to be in a situation where I’m spending days analyzing or optimizing.

I think most of us know by now that merely copying competitors’ features or business models is a bad idea. Jesse Weaver’s Emulation Is Not a Product Strategy does a very good job of explaining why this approach almost never works, and what to focus on instead. One example:

In focusing their efforts on emulation, product managers stop considering options that could enhance what is unique about the company and its customer base. They miss chances to deliver something powerful and unexpected. Instead, product managers should focus on unique strengths — those things their customers came for in the first place. In doubling down on those, product managers can exponentially increase a product’s value, deepening customers’ connection to the specific magic that makes a product special.

Product Management podcasts are a bit hit and miss, but this week there were two discussions that I found really interesting and useful.

First, on the Product Science Podcast, an interview with Teresa Torres on continuous product discovery:

Teresa Torres is a product discovery coach and the author of the Product Talk Blog. She spends most of her time coaching cross-functional product teams on how to adopt continuous discovery practices. On this episode of the Product Science Podcast, we get into how you can refine your product discovery practices.

And on the Product Experience Podcast, Tim Herbig discusses how to be an effective product leader when you don’t have “official” power:

Tim Herbig has made many mistakes (who hasn’t?). Fortunately for us, Tim not only owns up to his mistakes, he’s written a book to help the rest of us avoid making the same ones. We’ve all had issues with how to work best – not only within our individual teams, but with the rest of the organisation as well. In our conversation, he shares some simple and practical methods to diagnose when you have a problem and how to solve it.

Tim references Teresa’s work in his conversation, so the two episodes are really complementary as well, which is a nice bonus. Tim’s agile peer canvas to foster empathy within a team is also really interesting and worth looking into.

This interview with former Google and Flipkart product leader Punit Soni covers a lot of ground and is interesting all the way through. His thoughts on the importance of a go-to-market strategy is so important, and a trap many product managers fall into:

When an idea is finally in sight, it may be tempting to jump feet first into product building. According to Soni, founders need to resist the impulse to obsess over product to the exclusion of everything else at the very beginning. “It’s tempting to slip into a ‘build it and they will come’ mentality, especially if you’re convinced of your own product prowess. Now I’m a product manager through and through, but I’ll be the first to tell you that product usually isn’t the issue,” he says.

Instead, tackle go-to-market, working through who’s going to buy, why and what they would pay. “Product is more binary in that, either the tech will allow you to do it or it’s not possible. Making sure that you can build a sustainable business model around that product is a far tougher task,” Soni says. “Figure all of that out before you start a company, not as you go along. Once you check that box, then you can become a product-focused company.”

I really like Vrushali Paunikar’s approach to onboarding new product managers in an organization. In particular, the focus on three different time horizons with distinct goals is very important:

The first 30 days are about breadth. Put together a 30-day checklist broken up by people, product, and process to help your PM gain context and develop peace-time relationships.

The first 3 months are about perfecting execution. Give your PM projects she can actually launch within the 3-month window to help her establish early wins as well as learn your product development process.

At the end of the first 6 months, your PM should have a point of view on the direction of her product. Set this expectation early and empower her to own product strategy and vision.

One crucial point that is implied but not explicitly stated in Vrushali’s post is that PMs should avoid coming in with guns blazing in the first month and try to change/introduce a bunch of stuff. The first month is about really, truly, honestly listening and understanding. You’ll have plenty of time to have an opinion. Make sure you understand the context of the company and the product before you start having and communicating them.

For further reading on this, a while back I also wrote about What a Product Manager should focus on in the first 90 days.