Subscribe with Email

Featured Articles

In Summary: If you don't know Metcalfe's Law from Sarnoff's Law, or whether your product is unidirectional or bidirectional then this deck is for you.

Network effects occur when a product becomes more valuable to users as more people use it. Understanding network effects help Product Managers build 'moats' around their products that protect them from competitors and can create tipping points to 'winner-takes-all' market domination (think Facebook.)

But network effects are not the same as viral growth, nor do they necessarily confer 'economies of scale'. With case studies from AirBnB, What'sApp and FB, the A16Z team deliver a masterclass in network-ology.

In Summary: Having researched over 250 startups, Ted found no direct relationship between the number of validated hypotheses and a product’s subsequent success. Furthermore, the Lean Startup method might produce 'false negatives,' meaning good ideas get rejected because there is no clear rule for when to stop testing and begin scaling.

He concludes that Product Teams need a strategy to define boundaries and ensure experimentation isn't left to run rampant. Product Teams who focus in on a target customer segment, value proposition, and channel perform twice as well as teams that do not.

Ted's colleague, David Collis, has called for 'Lean Strategy' over Lean Startup. By combining strategy and experimentation, Product Teams can greatly increase their odds of achieving lasting success.

Making Product

In Summary: Product Managers are not a 'one size fits all' group. A company's need for the role depends on industry, type of product, type of customer and the team around them.

Few people are good at everything, but there are qualities all good PMs should possess. Good PMs lead and serve, manage expectations and focus on outcomes not releases. As Satya Patel points out: it's important to hire PMs for 'attitude over aptitude.'

In Summary: PMs who learn how to deal with data from collection to presentation, how to run experiments, how to demonstrate ideas through prototypes and how to speak the language of developers will become more valuable to their teams, and – most importantly – their users.

Product development is a team sport. Ultimately, Product Management boils down to one core skill: empathy.

In Summary: Product Managers are often faced with the challenge of deciding whether to deliver on a user need or an internal requirement. After 3 years as a PM, Jan believes in seeing everything from the customer’s perspective. Assumptions should be treated as what they are: unproven hypotheses about the future.

As a discipline, he is convinced that 'jobs to be done' thinking, combined with user-centered metrics, will become the de-facto standard for Product Managers of the future. Solutions should always come late in the product thinking process.

There are 2 kinds of Product Debt. Product Managers must make time to pay back both.

In Summary: Product Managers work hard to co-ordinate competing demands for new features and design enhancements within individual products. But they also need to synchronise the development of multiple products within an ecosystem.

Containing product debt requires an awareness of the 'multichannel' user and the 'unichannel' user and the honesty to recognise that certain products require immediate focus in order to avoid destabilising the overall experience.

It’s easier, faster and less risky to innovate on the web. So product debt often accumulates in native channels as development focus shifts constantly towards the path of least resistance.

In Summary: The key to a successful launch lies in careful planning. Product Managers should establish a clear plan early, keep it updated throughout, and make sure they involve internal stakeholders well in advance.

Launch day shouldn't be the first time a new feature or product gets in the hands of users. PMs should get feedback or share early prototypes before launch.

It's important not to announce launch dates too early as constantly shifting them out will damage your reputation. But you don’t want to be the company that always has new features coming 'soon.'

Post-launch, users need a way to share their opinions and the Product Team needs a way to offer customer support. Finally, it’s vital to look back to examine how the journey of the launch played out.

Talking Product

In Summary: For Product Managers, bots are a great way to serve users in a personalised way, especially in messaging products.

Product Managers need to know what bot is right for their product. Bots live in one of four quadrants, between the axes of engagement time and repeat use, and each quadrant requires a different type of bot.

In Summary: Peter's story is a compelling one for all Product Managers. An alumni of Y Combinator, he spent years building products no one cared about before eventually striking gold with Segment.io.

His advice? Make sure you really validate the problem you’re solving. Unless you're 100% sure you’re solving a real problem, you’re almost certainly not. When founders solve their own problems, it's less likely they'll screw up the concept as they already know what the problem is.

Early-stage Product Managers need to balance their 'reality distortion fields' with scepticism to ensure they're not deluding themselves and moving in a useless direction.

Designing Product

This week, the Google Ventures team published Sprint, a book about the rapid design method they employ with their clients.

In Summary: The Design Sprint was developed at Google Ventures. It's a 5 day process for answering critical business questions through design, prototyping and testing ideas with customers.

On Monday, you unpack a problem you want to solve. On Tuesday, you sketch competing solutions on paper. On Wednesday, you decide how to turn your ideas into a testable hypothesis. On Thursday, you hammer out a prototype. And on Friday, you test it with real live humans.

In his post on Medium, Eris Ries deep dives into the Prototyping Mindset: a philosophy that prioritises temporary simulation over long-term quality.

The ideal prototype should be 'Goldilocks quality.' If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish.

In Summary: Notifications are a privilege. Users place trust in you by allowing your product to send messages directly to them. You mustn’t abuse that privilege.

The most common mistake PMs make with push notifications is sending too many. Don’t send out notifications just because you can or just to lure users into using your app. Aways send them within a user's local time zone.

A successful notification strategy approaches message timing from the perspective of the user. It's not just about push. Diverse messages should work together in harmony to create a great user experience.

Before sending notifications, Product Managers should choose a goal and track the necessary metrics to determine if the communication worked.

Product Quote of the Month

Useful always trumps usable. If nobody wants to use it, usability is irrelevant.