Posted on

How We Got The IT Minister Excited About Indian Product Startups & Made Him Our Spokesperson #UnleashTheEnergy

A behind the scenes account of how a showcase of 11 disruptive startups was put together in just 100 hours!

If you’re reading this, I’m sure  you are a part of the Indian product startup community in one way or the other. And unless you were living under a rock (which is fine, if you were busy hacking away or traveling to sell your product), you wouldn’t have missed that our Hon. IT Minister, Ravi Shankar Prasad was in Bangalore on Tuesday meeting with the product startup community. iSPIRT hosted  the “Conclave for India as Product Nation #1″, an open dialogue between the Product industry and the IT Minister.

What made it all the more special was that the he was the first IT Minister to meet with startups and also that he first met with the startups first before meeting officials from his ministry! The Minister met with the industry leaders, gave a patient hearing to the needs of the product startups and also saw presentations from 11 disruptive startups.

And here’s what the minister had to say after meeting with the startups!

So how did we pull this off? And what if I told you that it was all put together in 100 hours. We ourselves cannot quite understand how everything fell into place! But as Sharad often says, when a bunch of passionate volunteers come together towards a common cause, magic just happens. At iSPIRT, we take our volunteering quite seriously. No wonder then, that we actually have open sourced our volunteer model through a whitepaper to help other communities benefit from it!

 

A text message from Rajan on Saturday morning got me involved. Could we get on a call, he asked. There’s an iSPIRT event scheduled on Tuesday and some help was needed. We spoke and I got to know that there’s an interaction with the IT Minister scheduled on the coming Tuesday. As part of the interaction, we needed to put together a showcase of disruptive product startups to help the Minister get a sense of the kind of impactful work being done and the opportunities ahead. There was list of companies drawn from across various segments and stages, with whom we’d need to connect and get their availability for the event on Tuesday. Tapping into our network of volunteers (many of whom are themselves startup founders and industry leaders), we gathered the contact details of these companies and started reaching out to the companies. These were companies spread across the country and we checked with their founders if they’d be available to present. Based on the availability of teams and the some intense discussion and debate among the Program Managers for the showcase, a short list of the companies presenting on stage was drawn up. The thought process behind the selection of companies was to give the Minister a good view of the breadth (sectors where product startups are making an impact), the depth (companies that have achieved global market/tech leadership) and how far they can grow with sound support from the ecosystem, which includes the government as well. We were immensely privileged to have Mr. Mohandas Pai spare his valuable time for multiple meetings through the whole process and share his inputs on what kind of stories would make the maximum impact.

Product Leaders with the IT MinisterArriving at the shortlist was surely a good beginning. They say well begun is half done. But the tougher half lay ahead! We were already at Monday morning, and within the next 24 hours we had prep up the presenters. Each of the companies were to have a short, crisp presentation with the key points to be covered in under 4 minutes! Shekhar went about this with the precision of a toolmaker, thoroughness of a scientist and the strictness of a school teacher! From putting together notes on what points to cover, iterating multiple times with the presenting companies on their presentations over a sleepless night, to conducting the actual showcase in front of the minister, Shekhar was always on.

(That’s me on the left  trying to get the slides up!)

The event received some very good coverage in the media. Below are some links:

Here’s hoping that achchhe din are indeed ahead for the Indian software product industry!

Posted on

Don’t Build Something Unless Someone Is Willing To Pay For It & Asks For It Twice!

Notes from the  Product Management Roundtable In Bangalore. Having attended the first ever iSPIRT Roundtable on Product Positioning in Bangalore and closely followed the second one held in Delhi, I was eagerly looking forward to the Round table in Bangalore on Product Management by Sridhar Ranganathan. Sridhar is a senior Product Management professional having spent considerable time in product management roles in companies like Zoho, Yahoo! and InMobi.

The 12 startups that participated in the round table consisted of a healthy mix of companies across various stages wrt their Product organization – some already had a PM function set up, some were scaling fast and were looking for ways to make their first PM hire and some where the CEOs or the founders were themselves donning the hat of a Product Manager.

The session started with a round of introductions and an open discussion around various aspects of Product Management – need for Product Management, hiring of Product Managers and setting up the team, prioritization, building an MVP etc. which set the right tone for the rest of Roundtable.


Sridhar shared his experiences of being a Product Manager and a Product Management leader in his previous roles. His experiences at Zoho were particularly of a lot of interest to the participants, as Sridhar was at Zoho during the period it transitioned from a company making Network Management Systems to the Saas giant it is today. He mentioned how the founders had a strong faith in setting up a Product Management function and empowering the Product Managers to lead the product efforts. He said it was like changing gears from moving in 4 big ships to 11 speedboats – with a Product Manager navigating each speedboat (a product). One insight Sridhar shared stood out, that the founding team needs to strongly believe that there’s a need for Product Manager(s) in the company and remain fully invested in the idea. Otherwise, there are very few chances of a Product Manager making a meaningful contribution and succeeding in their role.

Here  are some key insights from the discussions at the Round Table:

Product Management is a highly cerebral activity

The importance of setting a conducive environment for the Product Management setup was stressed upon heavily by Sridhar.  It is imperative that between the Product Manager and the immediate Product team (engineers, designers, QA), there be a very high amount of trust. The decisions of the Product Manager will directly impact the work, and subsequently the performance of the engineering team. Similarly, the Product Managers needs to believe that his engineers are capable and are able to solve the challenges he poses to them.  Laying the right foundation and building trust among the team is absolutely essential for the Product Management team to contribute significantly towards the company’s goals.

Framework to Solve Customers’ Pain Points

The discussion then moved towards prioritization of tasks, catering to customer requests for feature additions and customizations. Sridhar presented a very interesting framework which is quite handy to place customers’ pain points in the right context and solve them appropriately.

 

Depending on the target group size is and the complexity of the pain point, one can address the pain points in different ways

  • Education: Can you provide simple walkthroughs of the product through screencasts or tooltips, put down a set of FAQs that customers can refer to and get the help they’re looking for?

  • Process: Can you tell customers on how to do something? As an example, creating a 1-page document on how to apply for a passport and redirecting customers to that section would be a way of setting up the process.

  • Procedure: Taking the above example itself, if you actually build a feature to help customers apply for a passport, it would be creating a procedure to solve a pain point.

  • Solution: Any customizations/hacks over an existing feature/flow would fall under this.

  • Product: Enabling the customers to do something completely through the product itself. E.g. Employee payroll processing.

Building an MVP

How much time should one spend in building the MVP? One of the keenly debated questions was on the amount of time to spend to build an MVP. While there were multiple inputs based on the nature of the product and the market each of the companies was targeting.  However, Sridhar mentioned that one should invest enough time so as to avoid having to pivot at a later stage.

Is your product a ‘painkiller’ or a ‘vitamin’? It is important to understand this very well beforehand and pitch the product in the right manner to your first set of customers. You may be overselling if you’re trying to pitch a vitamin disguised as a painkiller and grossly underselling if it is the other way round!

What features get built into the MVP? Don’t build the product or a feature just because someone says it’s a good idea or if your prototypes ‘look good’. You need to validate that the customer is indeed willing to pay for the product. It’s even better if they ask for something repeatedly, which indicates that they have a pain point and they are willing to use the product/feature.

Taking the MVP to the market. Choose customers who can challenge you and make you think harder. The first 5% of the customers give 85% of the important feedback and the interest tapers off as you get the next set of customers. It is important to keep validating your view of the market and be ahead of the curve. You may have built something that was relevant at a previous time or maybe talking to a customer set that’s no longer representative of the larger market out there.

When to get a PM and what should the PM spend time one?

Sridhar suggested that whether or not there’s a formal designation assigned, there should be a Product Owner from Day 1, which is invariably one of the founders. Over time, it will be good if one can identify a good Product person from among the early engineers and have a Product person for a group of 7-8 engineers. The Product Manager should ideally be able to do 70% of everything! For the effective use of a Product Manager’s time, a helpful rule of thumb is that he spends 50% of his time planning for the future, 30% of the time on current initiatives and 20% of the time on firefighting.

Data, Intuition & Processes

How much does one trust data and how much does one rely on intuition to make decisions?

One of the participants remarked – “If you torture data long enough, you’ll get what you want”. It was general view shared among the participants and endorsed by Sridhar that data is good for discussions and not decisions. There’s a strong element of intuition and market understanding that go into making decisions and there should be ample scope for that.  Finally, it’s the Product Manager’s call on the direction of the product and he needs to be able to take views from multiple perspectives. Data alone being the decision criterion may not be the best way to go about it.

What about processes? Do they kill creativity or actually help in better productivity and accountability?

A quick poll on what the participants thought about process threw up some interesting responses. The hardcore engineers found process to be a bit of hindrance. However when they put on the founder/senior management hat, they found that there needs to be some way to maintain accountability and provide better visibility to a larger group as a company grows. As one of the participants rightly said, process is ‘doing what you say and saying what you do’.

Sridhar cautioned against having too many processes (don’t put policeman unless there’s a lot of traffic) ot of traffic), he also shared some interesting ways of bringing in process. Rather than enforcing process, can the employees themselves be stakeholders in implementing process and are ihe also shared some interesting ways of bringing in process. Rather than enforcing process, can the employees themselves be stakeholders in implementing process and are incentivized for taking an active part in the process and evangelizing it?

Each of the participants took away some key actionables which they’d go back and try out at their respective companies. They’d also stay in touch to share their learnings and experiences to help one another build a strong product management function. After all, we’re working towards transforming a nation with products!