Posted on

Why did I love this Saturday?

I usually start my weekends with an intense workout regimen. This one was also quite intense but in a very different way. I attended the 71st edition of ‘Playbook Roundtable’ on Saturday the 28th of May, 2016. Incidentally, this was my first time at any Playbook event. From the time I received the invite, I just had one question: how should I prepare to give it my very best? Little did I know that rather I would get the very best from this infectiously energetic tribe of people we call entrepreneurs on earth.

The event began at 11 A.M. with the first sip of cappuccinos and a brief introduction by everyone. We had 12 entrepreneurs (plus their co-founders), who had come to spend this Saturday to learn from one another. Besides passion, everyone was running high on desire to solve meaningful problems by using technology and change our world forever. While few of them had already (successfully) launched a product and were now facing next level growth challenges, many were still somewhere in MVP stage, figuring out product-market fit.

I was amazed to see an eclectic mix of problems these start-ups wanted to solve – beyond many industries and businesses. We had a renowned Fintech company making peer-to-peer banking easier with its latest product, a B2B engagement platform that helps convert one’s clients to promoters, a knowledge management product that makes life easier for customer support staff, a marketplace for those who want custom-tailored clothing minus hassles, an employee engagement platform that makes it easier to share ideas and innovate bottom-up, a mobile push notifications platform which has a unique ‘do it from your notification itself’ feature, an AI-based data cleaning & organizing tool, a personalized curated video platform which helps discover ‘still hard to find videos’ at YouTube, a collaboration platform which seamlessly works over Gmail, an education portal that aims to make multiple forms & cumbersome application process around admissions redundant, an open source ERP for small businesses with an enviable community across the globe, and a managed marketplace for getting super-affordable flash presentations. Phew, that was a lot… But that’s how best Saturdays are made!

The format of the event – with a handful of participants and an intimate setting over a roundtable, literally – allowed for an easy interaction for everyone. After hearing elevator pitches by everyone, we all were kicked to get into the next phase of our day – the demo!

Every entrepreneur had a total of 30 minutes to give a brief demo and then get into question-answer session, which was a unique opportunity for everyone. While a lot of questions satisfied curiosity of the audience, many entrepreneurs actually took on the audience by asking difficult questions that were giving them sleepless nights. “Almost everyone giggled when this young gentleman innocently asked – how do I reduce my cost of sales? And one response came – don’t ever sell to this segment!”

While everyone learned a thing or two, I noticed recurring themes in advice and insights that most of us agreed with. I call those timeless pieces and they are:

  1. Articulate the problem you’re solving really well (for whom, how, and why)
  2. Keep it super simple during MVP stage
  3. Speak to users, don’t assume
  4. Your product is super cool, but maybe for some other segment!
  5. Solve one problem really well for just a handful of users before conquering the world.

We concluded the session with everyone summarising their one or two key takeaways from these awesome 6 hours spent together (damn, nobody mentioned expanded LinkedIn network!) For me, more than anything, it was a humbling experience to be with these ultra-human beings for I’d like to be like them, some Saturday!

Posted on

Pricing your SaaS Product and how we did it at Sosio

In case you aren’t updated on the current affairs, 2014 is shaping up to be a controversial year; and we’re not referring to Justin Bieber’s antics, Mr. Kejriwal’s dharnas or Mr. Modi’s development stories. Instead, a new contention is brewing in the annals for us which is every entrepreneur’s one of the worst nightmare: deciding how much to charge for your product 😉

Pricing is one of the most difficult things to get right. There are several questions that come to us, and its good if we can get an answer for each of them. Should my MVP be free? When should I start charging? How much should I charge? Will I lose my first customer, if I start charging higher? Will the freemium model work?

We get into these FUDs(fears, uncertainties, doubts) because whenever you ask for money, there is friction, which cannot be removed, it can only be minimized. The best way to overcome these objections is to prevent them from happening. Well, I tried to study, how other people, were addressing the same problem, and tried to come up with one for my own product. Its taken more than 6 months, and hours of brainstorming with few of the amazing folks for me to reach here. I will try and summarize few of them.

The trouble with software pricing

Pricing is a basic economics thing. Unlike traditional manufacturing products, where there is a fixed cost of raw material, labour, transportation etc. a cost price for each unit is pretty clear. On this objective value for each of the unit, the sales team, tries to create a perceived value of the product, based on reference points of competing products, and after a basic survey of the demand curve, a price point is generally arrived.

For softwares, the case is slightly different. After break even, the price of a new unit, tends to be negligible. So defining an objective value for each unit becomes tough. Chances may be, the product you are creating may not have a direct competitor, or if there is an alternative it might be free. In that case, extrapolating from a reference point becomes tough.

The price tag you put on your software, is one of the most challenging thing to get right. Not only, it keeps you in business, it also signals your branding and positioning. Iterating on the product, is far more easier than on the price. Lowering the price is generally easy and appreciated but it takes to be an Amazon to demonstrate it profitably. Increasing the price, is tough, because it adds to the churn. So doing the most you can, to get it right, generally accounts for a successful business in making.

Addressing few of the initial Questions

Should I charge for my MVP?

Despite validating the problem that I was solving, and clearly mentioning the price point during the customer interviews in my initial stages, I used to be afraid of asking money for the product, because I had a fear, the product is not ready, the Minimum Viable Product was minimal, I was not sure of the hidden bugs and I was not sure, how deeply have I solved the problem.

The two thought leaders Steve Blank and Sean Ellis had the following to offer –

Steve mentions pricing to be one of the important questions in your customer interview, this helps you validate that the product’s value proposition is compelling enough for them to pay, and the problem is worth solving. Once the MVP is built, Steve asks you to sell it to your early customers. There is no clearer customer validation than a sale.

Sean Ellis, removes pricing to the post-product/market fit stage:

“I think that it is easier to evolve toward product/market fit without a business model in place (users are free to try everything without worrying about price). As soon as you have enough users saying they would be very disappointed without your product, then it is critical to quickly implement a business model. And it will be much easier to map the business model to user perceived value.”

Well both of them have their own merits. So I did an A/B with my customers. I offered two of them, the software for free, and mentioned to the other that we will be charging. The folks who were given free product, did not use it and it got shelved, whereas the ones who were paying, had feature requests, reported few of the bugs they came across, solving these bugs, and responding pro-actively helped me develop better relations with them. The free users asked for additional features, whereas the paying users asked for improved features, which eventually meant a better product.

Personally, I align more towards Steve’s side, because, the best validation you can get for products value prop. is the customers’ bucks, and if it gets figured out initially, nothing like it.

Should I go for a freemium model?

Lincoln Murphy has a white paper on The Reality of Freemium in SaaS which covers many important aspects to weigh when considering Freemium, such as the concept of quid pro quo where even free users have to give something back. In services with high network effects, participation is enough. But most businesses don’t have high enough network effects and wrongly chase users versus customers. The notable point in the above paper is – “Freemium is a marketing tactic, not a business model.”

People have struggled with freemium, and dropped it, with few exceptions of Wufoo and FreshBooks. The conversion for free to paid accounts has been relatively low even for Pandora, Evernote, and MailChimp. 37signals has greatly deemphasized their free plans to almost being fine print on their pricing pages.

Its not impossible to launch successfully with a free plan but things can get easy, when we simplify freemium, not look at it as a business model, with the only objective for it being to get people using your product in a manner that makes them want to pay for more advanced features.

What should I consider while pricing my software?

There are a number of ways to approach this problem.

The amount of money a customer is willing to pay, primarily depends on the following two factors –

  1. Value extracted from use of the product
  2. Emotional Willingness to Pay, which is an after effect of perceived value of the product.

And hence, two of the most obvious pricing strategies are –

Pricing based on the value provided

This is customer-first strategy. The amount of value each customer gets out of using Sosio, corresponds with the amount they pay us. Tried doing it, but devising an excel sheet, where in we could go and show, that you used sosio for X, and it increased your value Y times, is something, we are yet to find.

Pricing based on cost

This strategy takes care of our engineering team, sales cost, server and other rentals. This is generally intuitive from an engineering perspective. Pricing based on the number of accounts, the amount of data that is processed and saved, give us a good number, as to how much we should charge.

But the above approach makes it a uni dimensional pricing strategy. Our product is not just the product, its the customer support, its the number of users, its the problem that we are attempting to solve. The Quality of Support we provide, the response time of the support, Email Support versus phone support versus in person support, number of support incidents, product features and depth of usage are other metrics are other dimensions to reflect upon while deciding the pricing.

There are several params, to consider, and you can go on complicating your pricing and creating complex tiers. Even, I was doing one, till I read this post by Dharmesh Shah, and how he randomly arrived at a price of USD 250. I could have gone for a ballpark of maybe 20k INR, but here is how I arrived at what I arrived – I had few features, which other softwares, were providing as well. I have tied down features, uniquely, but my software, as of now, lacks the depth that these enterprise softwares offer, primarily for 2 reasons –

  1. those features will add to the complexity of the product and cost.
  2. the customer segment, I am targeting, does not require such depth.

What I tried was, brutally trimmed the price 10 times, of each of the features, and talked to customers. They were not willing to pay that much, but because I wanted to get started, I reduced it 50% further, the ones who were, happy, continued, the rest were a good bye.

With subsequent improvisation of the product, the prices will increase, and we will keep iterating on it.

Another advice, I got, while I was discussing my pricing strategy with Prof. Prem was to charge for the service and strategy. Well I don’t want to go into the details of how, an analogy can be if you are selling Adobe Photoshop, reduce the price of software, and charge for educational offers. It is working for me, two of my customers are happy with it.

Deciding a pricing tier

The four things to be taken care of, while deciding on pricing are –

  1. The price tier should be simple(Mixergy just uses the names of the plans as calls to action)
  2. It should be easy to compare, with the competitors.
  3. You should help people choose a plan.
  4. Avoid giving, too many choices. (The paradox of Choice)

An easy way of arriving at the tier is, creating customer persona, and segregating them.Your pricing tiers are a visual representation of where your buyers fit in your business model, and each tier should align to one type of customer.

Tiers makes sense for a lot of startups. But as of now, we are doing without it. Because based on the 50 customers I talked to during the sales process, most of them, got stuck, while I was explaining them the pricing model. If you’re a startup (or any software company) consider if your customers really need the additional pricing levels.

To end it all –

“Although scientifically purer, it often doesn’t make sense to change a single variable at a time. Theoretically, you shouldn’t change the price of your product, your discounting strategy and the types of bundle that you sell, all at the same time. But practically, it can be the right thing to do. It’s more useful to fix the problem than to understand why it’s broken. When a scientist goes on a blind date that doesn’t work out then, in theory, he should fix one variable at a time, and re-run the date. first, he should change the partner but go to the same film and buy the same flowers. Next, he should keep the partner the same, vary the film and keep the flowers the same, and so forth. but the pragmatist in him will, or should, change the girl, the film, the flowers, and buy some new clothes and shave too. If it works, he might not understand why, but at least he’ll have girlfriend.” – Neil Davidson

And this awesome piece by Seth Godin –

Go ahead and act as if your decisions are temporary. Because they are. Be bold, make mistakes, learn a lesson and fix what doesn’t work. No sweat, no need to hyperventilate.”

Guest Post by Saket Bhushan, ADFL at Sosio Technologies

Posted on

Interakt – an all-in-one customer engagement platform, Sudhanshu Aggarwal – Product Manager and Founder @ Fizzy Software, #PNHangout

Fizzy Software was founded in 2007 when I was doing my under-graduation in the US. Back then the Facebook platform had just come out and we saw that this could be an excellent opportunity to build some interesting apps on their platform and the first Facebook application that we built exploded well on the market resulting in us developing more Facebook and I-phone applications. We eventually sold most of those applications because those platforms were very new and we weren’t sure what this would end up resulting in. So we saw an opportunity and we cashed out our applications. I then decided to join Zynga as a Product Manager, where, for over a year, I worked on their internal gaming social network initiative which was developed to compete with Facebook. This turned out to be a great learning experience – lots of very smart people, lot of insights, focus on scale, speed and analytics, etc. However I chose to return to India in 2010 and resumed operations with Fizzy Software where I started a team in 2011 which focuses on design, analytics and feedback to build products and solutions for ideas that we came across.

Interakt.co

The idea for Interakt arose from a recurrent pain point that we observed while developing our products at Fizzy Software. Just to clarify, Interakt is an all-in-one customer engagement platform that brings lead capture, user data, email automation, live chat, web notifications and feedback under one dashboard. Over the previous years when we’ve built products, our goal was always to solve some problem. So we would find that one simple problem or pain point that we were facing and we would build solutions around that.

interaktAcross all these products that we built there was one underlying theme namely “customer engagement.” No matter what product we built, whether it was a B2B product or a B2C product there was always an angle of customer engagement involved i.e. how do you capture customer information, how do you understand what are they up to, how have they used the product, etc. Typically you would engage with your users by maybe sending a marketing email, automated email, informational email or transactional email. They might also have a query so you would want to respond to their support queries, get their feedback or engage in live chat. So there are currently a lot of different methods that websites and mobile apps use to engage their customers. Once we had built a number of products we saw this as one of the main underlying issues that we had to deal with every time we built a product. That is when we started diving deeper into what other solutions were out there and we learnt that we could build a solution which was probably better and more comprehensive and delivered the right value because of which we decided to build Interakt as a central customer engagement platform to allow you to capture, engage and entertain users.

Picking and Choosing

Currently, in terms of customer acquisition for Interakt, we are doing a number of things as I think it is too early to predict what is going to be the biggest customer acquisition driver in the future for us but content writing is a very big thing for us. We are also now trying to formulate a social media strategy where we use Twitter, Quora and other tools to generate more leads and reach out to more people and get their feedback from there. Other than that we are constantly parsing and collecting information about start-ups from blogs and other sources and putting that in our database and reaching out to them. Another big segment for us is our integration partners. We’ve integrated with Shopify, Prestashop, bigcommerce and we are going to be going after their customers and will hopefully win some partnerships and cross promotions with those platforms where we sell it to their customers. People are already used to SaaS based platforms and they understand the value of having everything in an integrated solution. So just like Shopify handles all the inventory management, sales, payment transactions for e-commerce stores, etc. hopefully Interakt could be the place where you manage your customer engagement, supporting your customers, sending them more personalised offers, etc.

At Fizzy software, we have a diverse portfolio of products. So when building a product, we first ask ourselves if we are building this as a viable business or are we building this just because we see a problem and we are really passionate about it. This is something that has helped us determine things going forward. Consequently, we have built products like EmailList.io, LaunchGator, etc. where the idea was we wanted a simple solution where it just did something for us where other solutions didn’t satisfy our need, irrespective of generating revenue from the product. In these cases we built these products almost as hackathons and just opened up these products other people. We sometimes even open source the code if we think it can be beneficial to others to see how we’ve done things. In the extreme cases where we do come up with ideas where we think these are really models or opportunities that could be big, then that is when the decision is to see if this a B2B product or a B2C product and based on that the revenue model decision or the business model decision comes in. We have clearly defined that any B2B product will be a SaaS based play and with respect to any B2C product we want to stay away from advertising. This is an internal decision that if we are doing a B2C product it should be something where there is an alternate source of revenue rather than just advertising dollars because in order to make a lot of money on advertising dollars you need millions and millions of hits on a daily basis.

While building our products, what has been important for us is being clear about the objective. What I have noticed through various discussions that I have had with regards to a MVP is that people have over thought the scaling aspect of things. For example, when I have 100,000 users or 500,000 users I should be able to do this which, in reality, is technically not part of your MVP. The whole idea of your MVP is just to put something out there and figure out your product market fit because getting to a 100,000 users is a very big challenge and it takes probably lakhs of rupees or a brilliant product or some other product features in there which will allow you to grow that rapidly. Dropbox had its own referral system. Evernote just had a great product to capitalise on. So a lot of people focus on scaling which is one thing that we’ve never thought of. Whenever we are building something we prefer to just plug-in basic features that work for that moment and if we have to re-do it once the product goes live, that’s fine. So scaling is definitely one thing we pushed back at.

Product Roadmaps are driven by customer feedback

The core philosophy has been about being able to build that basic MVP in addition to having transparency across the board. We want to make sure that whenever someone is building something they have a clear vision in mind and that everyone in the team is aware of what the other person is doing. Before we build anything however, we require thorough research into the competition and what tools are available in the market in order to enhance and build our product at least on par with what is out there today. I think doing enough market research and gathering enough feedback from people that is basically what should be your first step before you decide to build anything because unless you have Steve Job’s capability of just envisioning something and coming up with a break-through product on your own, most people rely on customer feedback and there is really nothing better than that. So just getting out there and talking to people and figuring out what their response is in order to shape your product’s future is important. A lot of times we’ve been guilty of not doing that. We just went with our gut instinct when we thought that the idea would make a cool product but then we’ve realised, from a big picture perspective, that customer input and feedback from all the stake holders is ultimately what should be driving your product roadmap.

#PNHANGOUT is an ongoing series where we talk to Product Managers from various companies to understand what drives them, the products they work on and the role they play in defining the products success.

If you have any feedback or questions that you would like answered in this series feel free to email me at appy(dot)sg@gmail(dot)com. 

Posted on

Why Startups are opting for Ruby to build their MVPs

“By the time that product is ready to be distributed widely, it will already have established customers”~ From the pages of “The Lean Startup” by Eric Ries.

It is essentially true that by the time you finish building your product completely, your customers are already looking for something new! Demands of your customers change in a snap. So, in order to match this lightening speed of change in demands, you need to be pro-active in identifying the problem and develop a minimum viable product (MVP) so that the product refinement process can be jumpstarted.

Once your MVP is ready, your startup can now work on modulating the engine and move ahead. Since speed is what a startup looks for when building a product, most developers are now turning to Ruby for web application development. Ruby can give you speed and ease in building your MVP. It is extremely efficient in assisting you to build a highly scalable app.

There are a number of reasons why Ruby is the top choice for developers building a minimum viable product for their startups. In case you are wondering why Ruby and not other languages, then –

  • Ruby comes with a low “learning curve”, which means that once you have crossed the initial hiccups, it is the most natural language to work with.

  • Ruby is a mature language with features like OOP, functional programming, multi-platform compatibility (WIndows, UNIX variants, Linux, BeOS, MS-DOS), minimum exceptions, Garbage Collection.

  • With flexible syntax and without any pointers, Ruby has great web development frameworks (like Rails, Sinatra).

  • Ruby does not incur any cost if you want to copy, modify, distribute and use it.Since coders can modify it according to their needs, coding does not seem restricted anymore.

  • Ruby has a vibrant open source community and a great support system. You can have a look at the source of the code, or suggest a patch, or get connected to helpful user communities as well the creator.

Ruby definitely comes handy to a startup trying to build a MVP. Time constraint is always there on startups. In such a state if a programming language comes with too many restrictions, it makes the task more difficult.There is no denial that startups with their MVPs are actually making it big. Any developer competent with Ruby language is the first choice of a startup. If you want to be in the coding world, Ruby should be the first language to learn. Not just because it is simple, but because it is rewarding as well. It has features that are convincing and can handle almost all exception well with its robust nature.

So, without delay, join Venturesity’s Ruby course. It is comprehensive in its course modules and is taught by industry experts. Expect the best guidance from our instructors who teach our students over live classes. What can be better than a hands-on training, an interactive class and project work to validate your learning! Register with us soon before time runs out!

“Startup success can be engineered by following the process, which means it can be learned, which means it can be taught” ~ Eric Ries

Guest Post by Pritha Bose, Content Writer for Venturesity

 

Posted on

First B2B Bootcamp for product startups – last day to apply

The last date to apply for this bootcamp has been extended to 16th August especially for Product Nation subscribers.

TiE-IQ Bootcamp is a no contract and free  60-day bootcamp where the participating startups will have an opportunity to create products, launch companies and walk away with their spoils and a lot of learning.

This first edition of the TiE-IQ Bootcamp is restricted to B2B technology product startups. It builds up on the successful bootcamp conducted by IQ earlier this year. Selected startups will walk in to the TiE-IQ Bootcamp with just a minimum viable product (MVP) and take back the following :

  1. Mentorship and Workshops by entrepreneurs leading successful startups to help you.
    • Refine and finish the minimal viable product (MVP) into a ready to buy product
    • Market your product
    • Get the first few customers
  2. Peer Learning
    • Learn from some of the best startup brains developing B2B products alongside.
  3. Working Space for two months in the heart of Mumbai.
  4. Software credits with some of the bootcamp partners
  5. Interaction with some of the best brains in the venture investment world.
  6. Demo Day: Your chance to pitch to investors in Mumbai  (and Bangalore – to be confirmed)

Who should Apply?

  • Enterprising (co-)founders and technology enthusiasts who want to build disruptive technology products or services for the Indian or global market.
  • Teams with 2-3 members that are capable to design, code and release a beta version of their product to market & sell it.

How to Apply?

To apply, visit this page for more details on eligibility criteria, and how to apply. The last date is extended to 16th August exclusively for Product Nation subscribers. For updates follow the twitter hashtag #TieBootCamp.

 

Posted on

Which feature to prioritize first ? – Wrong Question

When building a product it is very easy to make a list of features to build. One could brainstorm to create an initial list, copy features from a similar product or ask others (including potential users or customers ) via a feature wish list.

However which feature to prioritize and what to build first?  is one of the most burning question for  startup founders and early employees.

There will always be more features to build and add than there is the capacity or bandwidth to build.The additional challenge is even after building it is not clear if it was the right decision.

These decisions typically happen based on what one thinks is cool to build or someone has asked to build first.  For lack of a better framework to use to decide that is how things move forward but time runs out, product builder stand clueless what should have gone in the first place.

LeanStartup principles offer a framework for thinking about this. BUILD gets complemented by MEASURE & LEARN and which further loops.

At the beginning of an idea building an MVP is good step forward (which as we previously is tool for learning & may not be any feature of the product) to learn a little bit more.

With learning from MVP additional features can be decided upon. List each feature in terms in terms of the learning that they should yield along with a defined metric.

At various stage of a startup different metrics matter and come into play. For instance in the very beginning along with the MVP – validation of problem & solution is the important metric. Once that is established metrics relevant user acquisition, retention, referrals become important.

The first step to decide before periodization is to decide the metric for startup to focus on. Once the metric identified picking the feature become easy.

For instance for a product the problem/validation is established the next important stage is to acquire users really fast then to prioritize a feature ask the question “Does feature X allow to acquire users more by Y%”. Pick the feature first that will have the higher score for this. If development time comparison for the feature is steep then factor it in the trade-off.

In essence the question “Which features to prioritize to first” is to be really framed as “Which learning to prioritize first ?”

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!