Let's imagine that I've built a popular banking app. Let's call it M26. Let's imagine that people really loved the simplicity of my banking app. The users can signup, get a credit card by mail, and easily transfer money. This is the core of M26. We call this flow the fall-in-love-journey as this journey allows the users to very quickly realise the benefits of my product and fall in love.
As my banking app grows, the customer base also grows in terms of power users. The power users loved the simplicity in the beginning but now they need budgeting, a higher selection of credit cards, sharing accounts with friends and family, as well as web access.
The power users generate revenue for me so the thought of them leaving makes me panic. I build the features and make sure that their needs are met.
This example is of course purely fictional but it represents a pattern that I see over and over again in startups. These features for power users will often be mixed in with the core features and this is where the real problem is.
Before, a new user would signup, get a credit card and transfer money. To support power users they now have to signup, select a credit card - each card has a different price and level of customer support -, name their budget, take the tour of sharing accounts with friends and then they can transfer money.
For users that do not need the power features, they will most likely think that this is just as complex as signing up for the totally fictional and old school bank competitor, Leutsche Dank. This is because we are trying to serve everyone at once and that rarely works. My fictional banking application is suffering from complexity creep.
Protect Your Core
To prevent this, we would need to protect our core. This does not mean that we won't add features for our power users but that the simple hook that allows first-time users to fall in love with the product will become a holy site. And this holy site needs careful handling.
Budgeting, customer support, and account sharing are extra features that should be unlocked after the user has completed the fall-in-love-journey. Anytime any product manager, designer or developer has a great idea for your fall-in-love-journey it should almost get a no by default. This way complexity won't creep but instead, be discovered by the users as their needs grow. For some, this need will never be there and they can still enjoy using my banking application.
---
These were my notes about product development from week 10. See you next week.
As my banking app grows, the customer base also grows in terms of power users. The power users loved the simplicity in the beginning but now they need budgeting, a higher selection of credit cards, sharing accounts with friends and family, as well as web access.
The power users generate revenue for me so the thought of them leaving makes me panic. I build the features and make sure that their needs are met.
This example is of course purely fictional but it represents a pattern that I see over and over again in startups. These features for power users will often be mixed in with the core features and this is where the real problem is.
Before, a new user would signup, get a credit card and transfer money. To support power users they now have to signup, select a credit card - each card has a different price and level of customer support -, name their budget, take the tour of sharing accounts with friends and then they can transfer money.
For users that do not need the power features, they will most likely think that this is just as complex as signing up for the totally fictional and old school bank competitor, Leutsche Dank. This is because we are trying to serve everyone at once and that rarely works. My fictional banking application is suffering from complexity creep.
Protect Your Core
To prevent this, we would need to protect our core. This does not mean that we won't add features for our power users but that the simple hook that allows first-time users to fall in love with the product will become a holy site. And this holy site needs careful handling.
Budgeting, customer support, and account sharing are extra features that should be unlocked after the user has completed the fall-in-love-journey. Anytime any product manager, designer or developer has a great idea for your fall-in-love-journey it should almost get a no by default. This way complexity won't creep but instead, be discovered by the users as their needs grow. For some, this need will never be there and they can still enjoy using my banking application.
---
These were my notes about product development from week 10. See you next week.