Know when to stop, says Nathan Kontny.
In Summary: Many teams create a product that solves a problem well. Then they keep adding more and more to it. As a result, many products alienate their happiest users because they think they're not doing enough for enough people.
Product Managers should remember that the best users are already happy. If you keep adding more stuff just to make them happier, you run the risk of becoming less obvious and more bloated.
This doesn’t mean you should stop improving your product, but it does help focus. Never take your eye off what you already do well and focus on polishing the rough edges instead.
When you build a feature that’s extremely popular, the competition will steal it, says Hiten Shah.
In Summary: The vision for Trello was to create a wide product that was so useful just about anyone could use it. Which is exactly what happened. Trello's Kanban board may have been a supercool UX feature, but it wasn't a difficult one to replicate.
'Horizontal' products (which are useful in any walk of life) are hard to make money from. You can’t charge very much as you’re competing with other horizontal products that amortize their development costs across a huge number of users. 'Vertical' products are much easier to pull off. It's easier to find your customers and the margins are better.
If you want to build the next $1billion product, don’t build around a single feature that the competition can rip out. If you do, make that one single feature so deeply integrated into everyone else’s product that it’s pointless for anyone else to copycat it.
Next-level onboarding, from Samuel Hulick.
In Summary: Every time someone uses your product, they’re aiming to be transported from the situation they’re currently in to one they’d rather be in. The more comprehensively you provide assistance, the more people will survive the journey and continue being users of your product.
If someone is swiping around on Tinder, what happens in between that and them being on a date? Some users may be aiming for a long-term relationship, while others may be shooting for something less involved. It's the Product Team's job to figure out what happens in between.
To earn the ongoing engagement and retention of your users, take the cognitive load of 'figuring things out' off their plates whenever possible.
Measure the value not the feature, says Jeff Gothelf.
In Summary: When developing products, the relationship between what we build (output) and the intended effect (outcome) is often unclear. But management culture is set up to monitor outputs. Contracts and measurement tools can guarantee you're rewarded if you complete a feature. But they can't guarantee that feature will be successful.
Long ago, military commanders developed a system of leadership called mission command, an alternative to rigid systems of leadership that specify in great detail what troops should do in battle.
Instead, they give teams a strategy, a set of outcomes to achieve and a set of constraints, then give them the freedom to use their firsthand knowledge of the situation to solve the problem. Companies should empower Product Teams in a similar manner.
No big data = no AI, says Wallarm's Ivan Novikov.
In Summary: Artificial Intelligence has become a buzzword. Some startups are truly using artificial intelligence in their product. But most are simply using the term to attract new customers. In this post, Ivan outlines 5 questions that will help you tell the difference.
The most important factor is the nature of the data being used to develop the product. AI can’t become real AI without big data, period. For effective development, there should be real, big data provided. In most cases vendors use public sources such as government data or open source collections.
Next is the product demo. Can the product be demoed in a standalone context so you can be sure there's no manipulation occurring in the cloud? Also, can the product be demoed with your data or just data that's been preloaded?
Make sure you ask for details of the algorithm. Approaches aren’t trade secrets, so there should be no issue discussing what data is encoded and decoded.