hypothetical

  • Encouraging actions on a mobile home page

    High information density causes decision fatigue. It is a CTR killer everywhere. But more so on app home pages. Identify key decision variables and highlight only those. Put details a step away. (For example, when listing a deal, the price is important but location or rating may not be.)

    If encouraging exploration is an objective, then there needs to be novelty on the page. Customers will stop returning if they see the same thing every time. You are teaching them “do not expect anything new”. Not all apps can do this. And that is fine.

    Provide visual breaks. Exploration fatigue kicks in if customers see similar visual elements for too long. These can simply be differences in templates, or different types of content.

    The breaks are also good entry points to handholding actions. These nudge customers to the right section of the app without putting in effort. (For example, exposing content filters after a few scrolls.)

  • Breaking the Habit of Being Yourself by Joe Dispenza

    While looking for recommendations on mental health books, this one kept popping up everywhere. With its 4.8 rating on Amazon and 10k+ reviews, how could I possibly resist reading?

    But I stopped after the first 28 pages. The key idea of the book is that we can control our reality by controlling the “energy” around us. Supposedly backed by quantum physics. Yet two glaring red flags had me reading elsewhere for validation.

    This is what the book says:

    What quantum physicists discovered was that the person observing (or measuring) the tiny particles that make up atoms affects the behaviour of energy and matter. Quantum experiments demonstrated that electrons exist simultaneously in an infinite array of possibilities or probabilities in an invisible field of energy.

    Quantum physics calls this phenomenon “collapse of the wave function” or the “observer effect.” We now know that the moment the observer looks for an electron, there is a specific point in time and space when all probabilities of the electron collapse into a physical event. With this discovery, mind and matter can no longer be considered separate; they are intrinsically related, because subjective mind produces measurable changes on the objective, physical world.

    But only when an observer focuses attention on any location of any one electron does that electron appear. In other words, a particle cannot manifest in reality-that is, ordinary space-time as we know it-until we observe it!

    This is what Wikipedia has to say on the observer effect.

    However, the need for the “observer” to be conscious (versus merely existent, as in a unicellular microorganism) is not supported by scientific research, and has been pointed out as a misconception rooted in a poor understanding of the quantum wave function ψ and the quantum measurement process.

    And the citation to this point references a couple of scientists who should be trusted a bit more than the author’s views.

    Of course the introduction of the observer must not be misunderstood to imply that some kind of subjective features are to be brought into the description of nature. The observer has, rather, only the function of registering decisions, i.e., processes in space and time, and it does not matter whether the observer is an apparatus or a human being; but the registration, i.e., the transition from the “possible” to the “actual,” is absolutely necessary here and cannot be omitted from the interpretation of quantum theory.

     Werner Heisenberg

    Nature does not know what you are looking at, and she behaves the way she is going to behave whether you bother to take down the data or not.

    Richard Feynman

    By this point, the fundamental basis of the ideas presented in the book already look shaky. And the quantum physics ideas are an important basis for the key idea of the book.

    …with wilful attention, sincere application of new knowledge, and repeated daily efforts, you can use your mind, as the observer, to collapse quantum particles and organise a vast number of subatomic waves of probability into a desired physical event called an experience in your life.

    Mind and matter are completely entangled. Your consciousness (mind) has effects on energy (matter) because your consciousness is energy and energy has consciousness.

    In fact, everything material is always emitting specific patterns of energy. And this energy carries information. Your fluctuating states of mind consciously or unconsciously change that signature on a moment-to-moment basis because you are more than just a physical body; you are a consciousness using a body and a brain to express different levels of mind.

    Then came the reference to a research paper as “evidence” — Effects of remote, retroactive intercessory prayer on outcomes in patients with bloodstream infection: randomised controlled trial. This experiment shares evidence how prayers improved the health of patients, not in the present, but 6 years in the past. Right.

    So I looked up and found this — The Ethics of Joke Science. Here are excerpts from the article.

    Leibovici later wrote that he did not personally take these results seriously. They were intended as a reductio ad absurdum of randomised controlled trials for impossible treatments: 

    The purpose of the article was to ask the following question: would you believe in a study that looks methodologically correct but tests something that is completely out of people’s frame (or model) of the physical world.

    While Leibovici’s paper was intended as a spoof, Leibovici said that it was nonetheless an accurate description of an experiment. He stated that “the details provided in the publication (randomisation done only once, statement of a wish, analysis, etc) are correct.” As a result, I don’t think that people who took the paper seriously are in error. They are missing the joke, certainly, but this is not the same thing. It’s not as if Leibovici just made up his results. If someone believes in prayer changing the past, then they believe something absurd.

    With that evidence on hand, there was no reason to continue. Topics on meditation later in the book might be truly beneficial. Meditation obviously has benefits. But since the evidence behind the idea seems so flawed, with no burden of proof, I chose not to read it anymore.

    PS: A couple of other minor issues stood out as well:

    1. A book purported to be based on scientific evidence and postulating a new idea has the shortest list of references I have seen.
    2. Of those references, most seem to be non-peer reviewed. (I did not verify this rigorously. Didn’t feel the need based on what I already listed above.)

  • Designing an app home page

    In all mobile apps, the home page is the most important property. It’s always the first and most frequent interaction point for customers. The challenge is in keeping it relevant and fresh. Users seeing the same content every time will eventually stop expecting anything new and drop-off.

    But as with everything in life, it is not all black and white. It always depends on the nature of the app. Apps that naturally encourage exploration have it easier, while apps whose primary job is to induce actions (eg. transactions) have to focus on, well, actions.

    Social and e-commerce apps have it easier with user-generated content, product recommendations, extensive curation and merchandising. (These are not trivial problems, but the path is clear.)

    Need-based apps, like payments and travel, struggle since they don’t naturally generate new content. The most critical job for the home page is to ensure the primary need(s) is (are) satisfied first and foremost. Hence, the focus on actions.

    Often there is an “internal” push to make home pages of need based apps more “engaging”. Leading them to rely on listing deals and offers or some other form of force fitting. But this kind of content does not “cause” actions. The push to make such apps engaging leads to creating content for the sake of it. Which essentially draws the focus away from more important priorities.

  • Hiring Product Managers

    At Cleartrip I was involved in hiring more than 80% of all PMs who’ve worked there in the last 4-5 years. Along the way, I developed some personal heuristics on what to look for to predict success in the PM role. This is my personal approach. And this, of course, varies depending on how the PM role is defined within an organisation.

    Personally I think PMs should be responsible for an entire “flow”. As they grow, the number of such “flows” in their portfolio will also grow. Without this approach, there isn’t an end-to-end view of the customer. Which inevitably will lead to worse solutions. This means the way you evaluate a candidate also needs to adapt to this goal. So, here are the parameters that I evaluate when hiring PMs.

    Knows what they have done and why. This is what I focus on in the first interaction. CVs are a good elimination tool, but almost always inflated. So, the idea is to go deep into what the candidate has done in their career and understand if they know the why. It is surprising how many with very strong CVs fall at this stage.

    Comfort with data. Comfort with data is super important. Analyzing metric changes and having an intuition on the right metrics to track is critical for PMs. It is important to breakdown the problem before diving into what the problems might be. For example, I could ask — “conversion for the hotel funnel is down by 10%, what went wrong”. I am not really looking for what went wrong, but the journey she takes.

    Product thinking. After data, is an evaluation of product thinking. This will typically involve discussing a product that is live or being built or something that we have been thinking about. What I am looking for is the ability to think about user problems, jobs to do for users and constraints. What gets built is the last thing I want to discuss.

    Spikes and new learnings. This is a bit subjective. Here I am looking for things that we may not have thought about internally or something that is difficult for someone from a different domain to know. You will know when you spot this. This is strictly not a necessary factor. But helps with making the final decision.

    Ability to work with others. There’s no PM who works alone. How do they deal with conflicts with engineering and design teams? How good is the quality of requirements they produce? Without good requirements, engineering and design teams will end up working with ambiguity. And that’s not good. I will typically ask the candidate to structure a requirement document to evaluate this.

    Complement yourself. No individual is good at everything. But the team should be. Look out for skills where the candidate can add value where it is currently missing. This could be anything from marketing skills, design chops to experience working with customer support. It’s unique to every team. Decide accordingly.

    This is a framework I follow. I may end up overindexing on one of these depending on the role I am hiring for and the candidates’ past experience.

  • Principles for Managing Teams

    I have recruited and developed a team of high-performing product managers in the last few years. In terms of mentoring them to grow there are a set of principles, I try to stick to. This has evolved in the last 3–4 years. I am sure this will evolve in the future as well.

    1. To scale as a product leader, delegate and trust your team. If you cannot, you did a bad job of hiring. Take your time to build the right team. Spending time before a hire is better than after.
    2. “It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” — Steve Jobs
    3. Define clear responsibilities, goals and expectations, then get out of the way and let them do their job. Give freedom and protection.
    4. Be available always to guide and mentor them. Give feedback along the way — don’t wait for formal reviews.
    5. Dedicate time every week to discuss their week, guide them, brainstorm with them, set expectations and inspire them.
    6. Make being redundant your goal. If you are no longer needed for what the team is responsible for, you have done great. This frees up your time to focus on other things to push the business forward.
    7. Think of your team’s future, their growth. Work towards that — with them and in the background.
    8. Work to increase their visibility in the organisation.
    9. Take the fall for them and protect them from the rest of the organisation. But show them the right path to help them improve.
    10. Be honest and brutal with your feedback if they are off-track. But be clear with examples, expectations and a path to improvement.

  • Simplifying Product Complexity

    Over the last decade, I have been involved in building hundreds of features. Sometimes to add customer value. At other times to improve internal efficiencies. And many other reasons. The challenge has always been simplifying the solution. It is to find the sweet spot between the complexity of the build vs likelihood of risk or reward.

    I started off loving the complex solutions. But have wisened up since then. Here’s how I approach this today.

    Start with the problem. Think about the ideal solution that solves the problem completely for your customers. This is likely going to be complex and convoluted to build. (Which means you’ll be slower to market and, hence, slower is validating your hypotheses behind solving the problem in the first place.)

    Now evaluate the impact of solving the problem. What’s the outcome going to be? For your customer. For you. What’s the likelihood of that outcome?

    Now take a step back and question the solution. Does it need to be as complex? How much can you remove and reduce without reducing the benefits so much that the outcome is no longer useful — for your customers and/or for you?

    This step is recursive as you keep simplifying. Where you stop is determined by when:

    1. The outcome is likely to be no longer useful for your customers.
    2. The outcome is likely to be no longer useful for you.
    3. You can’t measure (1) or (2) by simplifying any further.

    What remains is something that is probably good enough to be of value to both your customers and you. (This is a simplification of explaining simplification.)

    Few examples of simplification I have used in the past.

    • Use a static CSV or JSON instead of an interface.
    • Hardcoding works. (If you can convince your engineering team.)
    • Assume defaults — remove choices and inputs.
    • Use rules instead of fancy algorithms.
    • Discrete selections instead of open-ended inputs (aka chat-bot).
    • Human-powered processes instead of tech solutions.

    The goal is not to create fancy tech. It is to solve a problem that your customers value. Bring in the tech once the hypotheses are validated and you need to scale.

  • Building Mobile Apps

    Owning Cleartrip’s mobile apps between 2014–16 was one of the most satisfying assignments I worked on. It was the beginning of the mobile growth years in India. We had the opportunity to shape the direction of the product. The team’s effort improved most metrics. There was external recognition as well. The app was selected Editor’s Choice on both App Store and Play Store in this period and won a few product-design awards as well.

    The success of the mobile platform also gave me the opportunity to be part of public discourse on mobile growth in India. Here are some mobile app development principles I had put together for a presentation during that time. Much of it is still valid.

    • It is still difficult to tap, type, correct and read on a mobile screen. Reduce and remove friction for these actions.
    • Reduce the number of taps required to reach a goal. Provide recommended starting points, combine actions to reduce clicks, ask for as few details as possible.
    • Reduce duplication, make it easy to find again. Remember recent and past actions, repeating inputs and “what I’ve already seen”.
    • Anticipate user needs and intervene. Assisted filters, fuzzy search and real-time input validation reduce stress.
    • Make it easy to assimilate information. Solve for aggregate (result-set grouping) as well as specific information (result metadata). Progressively disclose details.
    • Gracefully handle errors — ”What did I do wrong? What are the consequences? What should I do now?” Switching context to Google for solutions is stressful.
    • Solve for the journey; not the stop. Engagement brings users back. When users come back, trust increases. An increase in trust leads to (repeated) conversion(s).
    • What does a customer lose by leaving? What does a customer gain by staying? These are the best use-cases.
    • The best use-cases decay slower than others increasing retention. Encourage and guide users to these use cases.
    • Solve for mobility. Use device capabilities, solve mobile specific use cases (eg. near me, right now, share). But respect the physical limitations of the device — display, storage, bandwidth, battery. [1]
    • Respect the platform. Use first-party patterns where available. Don’t port patterns across platforms.

    [1] This is one aspect where things have changed significantly in the last 2 years. Most of these aren’t practical limitations any more. But that is no reason to be complacent. Behaviour (eg. concern about app size) is hard to change.

    [Update: 20 April, 2021]

    A thread on this on the occasion of Cleartrip’s acquisition by Flipkart.

Topics

Reading List

2024