Posted on

Bending India’s COVID-19 Curve Through Science & Data-Led Models

Powered by data-led scientific rigor, the India COVID-19 SEIR Model delivers early infection trends for every district in India. The model is geared to help Indians from all walks of life plan life and work decisions around their region’s projected trends over the next 15-30 days. Hospitals can use the model to plan for a surge in demand for resources (beds, ICUs, ventilators); local and national level leaders across private and public sectors can use the model to decide how best to contain the spread of the disease and re-open safely. Epidemiologists can use the model to define how different behavioural and environmental factors affect disease transmission. We introduce 3 use cases in this blog post—the first in a series aimed at promoting scientific and modelling capability. 

Wherever the Coronavirus curve has bent to our will, it has happened on the back of behaviour changes based on data-led insights. Everywhere, simple shifts in behavior—staying at home, wearing masks, sanitizing hands—have been informed by predictive models that showed us the mirror to a dystopian future if we didn’t edit our lifestyles. As a digital public good for a billion Indians, the value of the India COVID-19 SEIR Model lies in its reach and widespread use. 

Until a vaccine is developed, we have to make sense of today’s numbers in the context of all our tomorrows. Individuals, policymakers—and everyone in between—can make smarter decisions if they know the evolving shape of the outbreak, and the India COVID-19 SEIR Model aims to do just that by enabling identification of potential trends and patterns in the next 15-30 days. 

The approach taken by the model provides flexibility and utilisation from both a view of trends as core model adoption/enhancement.

We can all use it to bend India’s curve. That’s the ultimate use case, really — where the model tells us where it’s going and we, in turn, steer it in an entirely other direction. Models will change and that’s a good thing. It means we are responding. The power of models and data science in this particular moment is the ability to assist a very scientific approach to scenario planning during an ongoing pandemic.

We can turn the course of this pandemic and transform what this model tells us, every 24 hours. We are already watching the shape-shifting in real-time. It’s in your hands. Go on, try it. 

Use Cases

User — Individuals & Businesses (PDF format)

User — Scientists (PDF format)

User — Policy-Makers (PDF format)

About the contributors: The blog post is co-authored by our volunteers Yashvi Jaju, Nikhila Natarajan and Srikar V Cintalagiri

Posted on

Announcing the CIO Mentorship Program for Enterprise Product Startups

A ‘startup’ is a company that is confused about – 1. What its product is, 2. Who are its customers, 3. How to make money.

– Dave McClure

As a startup we all struggle either with the Market Fit, the right price for the product and finally the sales. There have been times when we have wondered if the product is perfect or I could have added some new feature, all the while loosing time to launch the product. When the product is out we wrestle with how to sell – Free, Premium or Freemium models and wonder, when will we get to close the big orders. We wonder why our product is being outsold by our competition – What does he have that I don’t.

We sometime wish that how wonderful it could be if we could share our thoughts, bounce our ideas with someone who could understand us and help us in a sustained long term manner, in short become our Guiding Lights as Mentors.

To help startups with just this dilemma, we are pleased to partner with CIO’s of leading Indian Enterprises to put together the CIO Mentorship Program. Where some of the very recognized CIO’s of the Industry from Hero Motors, BMW, Ericsson, Matrix, Max NewYork Life, Moser Baer are ready to use their collective wisdom and experiences to help the startups scale over a sustained time period of 5 months.

If you are brilliant Enterprise Product who is willing to take advice, implement advice and share your pain points then this is just the opportunity. So if you are operating in HR, Education, Data Analytics, Cloud, Mobile applications, CRM’s then you need to apply here. This is only open as of now for companies in NCR region. The last date of getting the entries is 17th Dec. Only the short listed companies will be contacted for the event on 21st Dec in Delhi NCR.

Posted on

Enabling Product Managers to manage Product Experience

In my last post, Product Manager, or Product Experience Manager, I described the disparate features and experiences that got broken in SiteZ and made the case that product management team should be responsible for overall product experience. In the final post of this series, I will present my views on how product management team should manage experience so that such issues can be minimized or avoided. Note that I am not talking about creating initial product experience or its next version, which is a topic of itself. I will focus only on managing the product as it goes through incremental changes.

There are 3 questions that must be answered by product management team at all times (and should be asked periodically):

  1. Are we seeing all the activities we should be seeing?
  2. Are we processing all the activities we see?
  3. Are we making good decisions based on our processing outcomes?

Product Experience Contour

To answer first question, it is important to understand the boundaries of the product experience that you wish to provide, what I call Product Experience Contour. If you define this too narrowly, you will miss out on lots of user and system activities that you should pay attention to. If you define it too broadly, you will be inundated with activities that are not useful and you will be stretched thin. There are 3 approaches to draw this contour:

  1. Persona-driven: If you have created personas (a realistic and detailed description of a fictitious user who represents a category of target audience for the product), they are good starting point to define these contours. Any activity in your organization that impacts or is impacted by a persona is usually a candidate for being on your radar. For example, if I am a persona for SiteZ (someone interested in learning from experienced people, but not interested in changing jobs), the product management team needs to ensure they are plugged into what the other group is promising and offering me. Note that in this case, I may not be a persona SiteZ cares about, which is a marketing and positioning strategy.
  2. Use case driven: If you have created use cases (UML, flowcharts, long documents, whatever) to describe how user roles interact with your system, that also is a good starting point though it may not be comprehensive. You can start by looking at the alternate and adjacent flows the particular user roles can go through on your system and see if those need to be on your radar. Use cases are more constrained because they describe your understanding at the time of product creation, while persona allows for more contemporary interpretation.
  3. Data-driven: While this may be hard (depending on how evolved your data analytics team is), this can be a very useful way to draw the contour. If you are able to analyze the data available for your system for past user interactions, you should be able to enumerate user activities (along with frequency of use) that you are interested in. The problem in this approach is that if some flows can’t be completed successfully by the user, or your data capture is not comprehensive, you may not get to know about some flows.

If possible, you should use more than one approaches above to draw the contours. Usually, persona-driven is a great way to draw initial contours, validate it with the data from your analytics, and then use data-driven approach to detect new user activities that might be important to include in the contour. In my case, it is entirely possible that none of my activities were ever tagged as useful activities to track, since these are not primary use cases (except the first one – trying to register to join the chat with the guest).

Information Sources and Management Systems

To answer second question, it is very important to look at 2 aspects:

  1. Information Source: As a user interacts with the organization, information is generated at many different places. It is very important for product management to be well-connected to these sources and make sure they are getting the information frequently. A few of the sources are:
    1. Data Analytics: As mentioned above, data analytics is a great source for information and must be harnessed properly.
    2. Direct User connect: There are many ways to connect directly with a sample set of users and keep learning about their experiences from them – product blogs, twitter, facebook and other social media channels are very effective if users can stay engaged.
    3. Be the user: It is surprising to see how little product managers use their own products on a regular basis. While being your own user may not be the greatest way to design a new product, it is a great way to keep tab on how things are going. Depending on the product, product managers can enlist their family and friends to be regular users and give feedback.
    4. Other departments in the org: Many departments interact with the users Product Managers want to know about, so it is very important to have a good flow of information from these departments. Typically, Marketing, Sales, Support, and Training teams can have good information about the user that should be captured.
  2. Information Management Systems: How information is captured, stored, and disseminated is very important for effective processing. Most activities can’t be processed in real time. Processing can mean many different things – I mean it in the sense of understanding, clarifying, analyzing, ranking and other handling of data. Product management teams need to procure, and use a management system that serves the purpose, and avoid leaving information in emails, chat boxes, whiteboards, or in their minds.

Good Decision-Making Process

To answer 3rd question, we need to make sure we have a good decision-making process in place which is used all the time. A good decision is a collaborative effort, and it is a process rather than a moment. It requires lots of data (which your information sources and management systems can provide), and it requires following a rational decision-making process. Such a decision-making process has following characteristics:

  1. Right stakeholders in the decision-making are identified.
  2. Participants are contributors and idea-providers, not spectators.
  3. Decision-making criteria (how will different options be ranked and prioritized) is defined before solution options are figured out.
  4. Personal responsible for the decision (and its consequences) is clearly identified (and it must be a person, and not a group).
  5. Once the decision is made, it is communicated, along with the rationale for making this particular decision.

In this context, since we are talking about incremental changes to product, the decision-making criteria should be known upfront and should be applied consistently. Impact of a change needs to be validated against all the known implications to the personas we care for, and this should be a key data in the decision-making process.

Evangelizing Product Management role

Even when you have great answers to the questions above, it is important to enlist the support of rest of the organization in keeping product experience awesome for the user. To do this, product managers need to be product evangelists who go out and talk about the product and their role as the guardian of product experience, to whoever cares to listen, and whichever platform they find. Once enough people in the organization realize that they should talk to you whenever they think about tinkering with the product experience, you will have created the strongest source of information about user activities and your product will thrive.

One final time, let me go through the list of issues, and show how they could be caught if above is done well:

Issue Solution
They misled the user about the time it takes to register. Evangelism would make sure they talk to product team, and good decision-making process would ensure that either advert is corrected, or product is fixed.
They didn’t allow the user to abort the registration attempt gracefully (which left the email address behind and created rest of the mess). Good decision-making process would ensure right prioritization, and if feature is not prioritized, user is provided enough information about what to do in this situation.
They were not forthcoming about who is sending me these spam emails (the email address was hidden with a display name that was the advertiser’s). Being connected to user (or enlisting friends and family as users) might flag the mail as inappropriately crafted (you are receiving this mail because.. line should be at the top somewhere).
They exposed a feature to me (unsubscribe) which didn’t work Good decision-making process should ensure that an alternative exists if this feature is not going to be implemented, and that user is told about it honestly
They didn’t give me an easy way to delete my account – emails bounced, UI didn’t have a button to delete, etc. Good decision-making process would ensure right prioritization, and if feature is not prioritized, user is provided enough information about what to do in this situation.

To be fair to SiteZ, it is hard to do all this because these are elements of organization culture and everything can’t be written down as a process and followed. Also, it is entirely possible, that they are indeed doing all this (though I highly doubt this!) and still I became a victim. Such caveats aside, I think this is a good discussion about product experience and hopefully companies will focus more on product experience than what they do today.

This concludes my series on Product Experience Management. I look forward to your comments and thoughts on the topic.