Notes from @sliceit_’s mobile engineering team on the things to keep in mind before implementing Android’s dynamic feature delivery.

https://engineering.sliceit.com/2020/09/30/dynamic-feature-modules/

Some developers, when confronted with a problem, think “I know, I’ll use the latest fad/tech/framework/language”. Now they have two problems.

The question is never—Should I do that thing?

The question is always—Why should I do that thing?

Trying out an experiment.

Summarising my blogs as Twitter threads.

Brace for it ⚡️.

https://abhyrama.com/

• A thread on product development.

  @abhyrama: Trying out an experiment. Summarising my blogs as Twitter threads. Brace for it ⚡️. https://abhyrama.com/

• If the success of your product depends on changing a deeply ingrained habit, it is going to be challenging.

  Your product should be attractive enough for people to overcome the inertia associated with behavior change.

• Sometimes, the most crowded markets are ripe for disruption.

• Competition may not always be harmful, especially when you are trying to create a new category.

• Think about product ownership and usage asymmetry.

  Ex—online payment solution for schools.

  Parents want this but the want is not strong enough to use this as criteria for picking schools. A product that exhibits asymmetry needs to have powerful incentives for both sides.

• Every time a customer reaches out to you; it is an opportunity to make your product better.

  Product enhancements should stem from customer service requests.

• Users will find unique ways to use your product, which you would not have thought.

  @abhyrama: Good products will be used in ways beyond the wildest imaginations of its creators. Some apparent examples - Github as a collaborative crowd-sourced document store, Twitter as a replacement for long-form blogs.

• More features are not always better.

  Be ruthless in culling features. New feature addition is a tug of war between simplicity and complexity.

• Do not get attached to a feature based on the amount of effort you put, the technology used, or the uniqueness of the idea.

  Usage is the only benchmark for a feature’s success.

• Customers do not always know what they want. Be careful while actioning on user feedback.

  Look around your house to see the plethora of unused stuff you brought thinking you need them.

  Mix your product insight and intuition with customer feedback before acting on them.

• You need something, does not mean the entire world is craving for it.

• You spot a problem does not mean others are looking for a solution to the problem.

  People are happy to live with minor inconvenience than change their habits.

• Do not look at product features from your point of view.

  You might have a refined sense of UI, but your customers may not. Always assume a customer-centric viewpoint.

• Assume no one reads anything.

  Figure out ways to make instructions implicit in product flows.

• Treat customers differently based on their lineage.

  Someone new to the product needs more hand-holding than one who is used to the product.

• New features may not pick up on their own.

  Figure out ways to incentivize a user to try out a new feature.

• Do not be drawn to complexity.

  A simple feature trumps an overly complex one.

• Figure out all the metrics to track before launching a feature.

  If you do this post-launch, it becomes a shifting goalpost where you are trying to prove the success of the feature rather than figure out whether it met the intended goal or not.

• The blog.

  https://abhyrama.com/2019/08/15/thoughts-on-product-and-feature-development/