Posted on

Product Led Growth

The software product industry is swiftly graduating from desktop to cloud based applications. Interestingly, there is also a hand-in-hand shift in the associated sales and marketing strategy around these products. Till some time back, a typical B2B sales cycle was heavily dependent on building relationships, and hand-holding the prospects through the product implementation. In this new age however, the products are driving the sales and marketing by themselves.

Let’s define “Product Led Growth”. For this, let me ask you a question: What is common across all of the below products?

Product led growth

The answer: all of them are in the MULTI-million dollar club! All of them have demonstrated an exponential growth in business, and all of them are being used by millions of customers around the globe. And then, what else?

Well, its simple: all of them have minimal setup and minimal implementation time. Any person can simply go to the website of these products, and get him/herself started; all within a few minutes. All of these products offer a free trial and/or a freemium version: and it is exceptionally simple for anyone to start using these products. And this is exactly the definition of “Product Led Growth”.

“Implementing the product is faster than selling”

Jeff Lawson from Twilio (@ SaaStr ‘ 2017)

“Product Led Growth” is a concept where the product sells itself. Quick on-boarding of customers, and simplicity of the product become the reason for their exponential growth. There is no hand-holding of customers, and there is no requirement of any explicit sales effort.

It is important to get the customers to identify the ‘value’ of the product in the shortest amount of time. The product must show-case its most important feature (I like to call it the ‘aha’ moment of the product) in the least number of clicks and the least amount of time. Free Sign-Ups and Freemium packages are a very useful ways to achieve this goal. The ABSOLUTE best way to show a customer that the product solves his problem is by having the product to solve his problem. If the product is able to demonstrate ‘value’, then it’s easy to convert the customer into paid accounts.

“Self service is the core to our DNA; and the reason for our growth”

Mikkel Svane from ZenDesk (@ SaaStr ‘ 2017)

Let’s pick on the example of Slack:

(1) Free Sign-Up: Any person and/or organization can simply jump onto the Slack website, and get started. Getting Started does not involve any physical sales intervention and/or any payment formalities.

(2) Implementation Time: It takes less than 2 minutes to get yourself started! Slack provides an extremely simple, step-by-step process flow to receive the required information.

(3) Tutorial: What’s more, once you get into the product, you are welcomed by a SlackBot, and a series of screen overlays that tell you everything that you need to know to start using the product.

(4) Retention and Conversion: This is the best part – till 10,000 messages, Slack is Free. And by the time you exhaust your limit, you get so hooked-up to the product, that you feel good about paying for it!

More often that not, I come across a lot of startups in India, that struggle to hire expensive sales teams, even to reach out to retail customers. Right here, is a solution: there is much a lot to learn from the success stories from around the globe and identify the reasons for their success and growth. In essence, a product that is easy to use and simple to on-board can and will sell itself. With an initial kick and strong push from marketing, your products can quickly become their own self-sustaining entities. And once you have a self-sustaining entity, you can use the money that you’ve made to hire your sales teams, and focus on selling to enterprises.

Guest Post by Pranab Agarwal, Product Head @ RateGain & Co-Founder, ZipBoard.

Posted on

Indian E-commerce: Moving on from GMV

It has been a nervous month for the professionals working for internet and e-commerce companies in India. Shutdowns and layoffs have been the flavour of the month, and business models have come under scrutiny. The effects of recent events at Stayzilla and Snapdeal have not been limited to job losses only. Weighed down by these developments in the sector, Rakuten, the Japanese e-tailer, has puts its India plans on the back-burner.

Stayzilla, an alternate and homestay aggregator, has shut operations. Investors including Nexus Venture Partners and Matrix Partners have invested USD 33 million across multiple rounds in the company. The founders have promised to bounce back ‘with a different business model’.

Snapdeal, announced that it will lay-off about 600 employees from the company including from its Vulcan (logistics) and Freecharge (payments) business divisions. The company has so far raised USD 1.75 billion from investors which include global heavyweights such as Softbank, Kalaari Capital, Temasek, Alibaba Group and eBay. However, Snapdeal reportedly is left with less than enough cash to survive the next 12 months. The merger talks with Paytm, facilitated by the common investor Alibaba, are not murmurs anymore and seem to be the logical next step in many ways. A very honest and important insight on the business model emerged from this episode, in which the founders admitted to ‘doing too many things’ and ‘diversifying and starting new projects while we still hadn’t perfected the first or made it profitable’.

The above incidents highlight the fact that Indian e-commerce in 2016 has been significantly different from its ‘glory days’ in 2015. GMV growth in 2016 was flat, even though long term prospects remain intact for now. The year-end sales were also impacted due to the demonetisation exercise carried out by the government. The cash on delivery (CoD) transactions, which account for approximately 50% of total GMV, were severely impacted due to the lack of availability of the new currency notes.

Figure 1: India e-tailing GMV (USD mn)

Source: Company data, IAMAI, Euromonitor, Credit Suisse

AHHHGMV, as the supreme emperor of metrics, has lost its sheen and the challengers which have come to the fore include revenue per customer (function of number of orders per year, value per order and commission), net promoter score (a measure of customer satisfaction) and overall user monetisation (including alternative sources such as advertising as well as new service offerings such as hyperlocal services).

The sustainability of business model is back in focus as a tool to evaluate potential winners and losers. Throwing money at the customers as discounts has not worked out very well for a lot of players. There has been a definite move towards trying to find other means of retaining customers. Going forward, winners are most likely to be companies that provide a differentiated customer experience. An obvious example is Amazon Prime which now brings more personalized experience to the company’s customers. Flipkart (Flipkart Assured) and Snapdeal (Snapdeal Gold) have similar offerings to enhance the stickiness of their customers. While ‘Flipkart Assured’ has seen limited success so far, Amazon Prime, launched at a very attractive price point of INR 499 per year, seems to be more suited for success going forward. Amazon has also clubbed its Netflix challenge – Prime Video offering with Amazon Prime subscription. With these offerings, the companies are trying to take focus away from discounts and towards customisation, quick delivery, consistency and reliability of shopping experience.

The control over supply side is a key element of constructing an enhanced and consistent experience for customers. Logistics is one of most prominent cost items for ecommerce firms, and depending on the category and value of the goods being delivered, could be 10% to 20% of GMV.

In India, the number of Amazon fulfilment centres has grown to 27 by the end of 2016. Shipping from stores is less efficient than from dedicated fulfilment centres. Amazon is looking to replicate their success in North America where they have invested billions in network of fulfilment centres. It has more than 75 such centres in North America, covering 25 US states. This gives Amazon an easy two-day reach over the entire US. Snapdeal has opened 6 logistics hub during 2016, with an estimated investment of USD 300 million. Paytm, flush with a USD 200 million funding from Alibaba, is reportedly firming up plans for a significant strategic investment in a logistics firm to improve its deliveries process.

The key growth drivers for e-commerce in India remain in place. There is a large aspirational population, faster and wider internet access, a never before push on digital payments and an opportunity to further penetrate the offline organised retail market. Nevertheless, the year 2016 has been a reality check. The Indian players have had to review their business models and take some tough calls to focus on sustainability. While the market may continue to be volatile in the short term, with more potential shutdowns and/or consolidation in the offing, we can now be more confident that the firms that do survive will turn profitable soon.

arvind-yadav

This is a guest post by Arvind Yadav,

Principal at Aurum Equity Partners LLP.

 

Posted on

You may have a viable product but do you have a viable business?

(Also posted on LinkedIn here).

I’m a big fan of the “Lean startup” movement. Steve Blank, Ash Maurya and others have done amazing work around innovative, startup companies. Two of my most recommended books in this area are The 4 Steps to Epiphany and Running Lean. I strongly recommend every founder read these. Shockingly, most haven’t!

I’ve come across a new breed of founders who are well versed in the lean startup methodology. They understand the importance of customer discovery, a minimum viable product and the power of testing. These are all necessary to build new products.

I submit that they are not sufficient to create a company.

Here’s why.

A feature isn’t a product; a product isn’t a business; a business isn’t a company; a company isn’t an organisation.

Sanjay Anandaram.

Here are four additional questions you need to look into before you startup.

1) Are you talking to the right, representative prospects to validate your idea?

I’m a big believer of getting out in the field and talking to customers. Dozens even 100’s of them. It is an order of magnitude better than sitting in your office and pontificating. However, talking to 200 people does not make your idea into a viable business opportunity.

Are these 200 people truly representative of the prospective customer pool ?

Or, is there a selection bias? Perhaps, these are only tech-savvy customers in urban areas or the upwardly mobile. You need to estimate how big is that addressable market over the couple of years.

Secondly, how critical of a pain point is it for these users?

Is it an ongoing pain or a one an infrequent, perhaps even a one time, problem ? In general technology has made people be more open to saying “yes” more often to new ideas. This is the classic Aspirin vs. Multi-Vitamin question that VCs often talk about. While new ideas area interesting, it often takes years to change customer behaviour unless it a dire problem for a large number of prospective customers.

Don’t try to “invent” demand. Find basic human needs and solve them better, cheaper and faster.

Evan Williams, Co-founder of Twitter.

Market creation is hard for a variety of reasons; one of the primary reasons is that the cost of distribution is continually getting more expensive.

Lastly, would customers pay — ideally with money or at least with their time(e.g. Snapchat, Instagram, Google)?

2) Can you get effective distribution of your product or service ?

Human beings and businesses alike are being bombarded with a breathtaking innovations at a rapid pace. However, the amount of time, energy and money they have is limited.

How will you reach a large number of customers whether they be consumers or businesses? Are there existing channels that you can tap into ? Would they be cost effective?

Every innovator believes that their product will have strong word of mouth, virality and/or some kind of network effects? Well, most don’t. For most ideas, esp. in B2C, I would be very dubious if you don’t have strong, organic user acquisition channels to grow.

3) Are the unit economics viable?

So you have a problem worth solving, a solution that’s differentiated and a shot at distribution. Now comes the question about “Unit economics”. The simplest place to start is with your gross and net margin. How much money would you make per transaction (or unit of engagement)? This is not GMV or Transaction Value but the money that your business makes.

The first step for this is to calculate your Contribution Margin, or the money you make per transaction less your variable costs. For most businesses, variable costs are marketing, payment gateway charges, delivery/logistics charges, etc. This does not account for fixed charges for your employees, server costs, etc.

Is your margin or take rate (%) enough to cover your variable costs per unit?

If you are relying on scale to get your contribution margin positive, you are barking up the wrong tree! You may never get there.

4) Is there a large enough profit pool to tap into?

If you’ve gotten this far, you clearly have a problem, distribution channel and business that’s worthwhile.

Is there a large enough market size and profit pool in the area that you are in?

I don’t know about these new valuation metrics, but remember that the only way to value a business that will always be true is: present value of discounted future cash flows

Prof. Bill Sahlman, HBS, Circa 1999

If you don’t have a large enough profit pool, you may build a company with great unit economics on a large enough market but have little discounted future cash flow (e.g. IRCTC — Indian Railways). See Rajan Anandan’s prescient comments on the Indian B2C e-commerce marketplaces.

Now comes the source of capital to build your business. If you are aiming for something big and ready to scale fast, then I would recommend using venture capital (if you can affirmatively answer all 4 of these questions, give us a shout at Prime Venture Partners). However, VC money may not be appropriate or relevant for your business or your approach. Here’s one representative list of questions to ask yourself before raising VC money.

All of this won’t be empirically figured out on Day 0 of a startup. Of course, you will learn along the journey. However, you won’t be able to change the contours of the market or the availability of profit pools once you are 6–12 months into your startup.

It behooves you to spend a few weeks or even months to think through these questions before you commit yourself to a new company!

Guest Post by Amit Somani. He is a Managing Partner at Prime Venture Partners, an early stage VC firm based out of Bangalore, India. Prime invests in category creating, early stage companies founded by rock star teams. Prior, Amit has held leadership positions at Makemytrip, Google and IBM. He is also deeply engaged with the early stage startup ecosystem in India and actively volunteers with iSpirt, TiE and NASSCOM. He tweets occassionally @amitsomani and is trying to become an active, late blooming blogger.

Posted on

From Bootstrapped to Angeled : Is it your idea or product ?

You’ve shaped up your business idea to flag off. You have a pool of talent believing in that idea and lined up with working prototype with feedback. Now, it’s time for funding to take your idea to concept to design to product to a successful business.

Depending on the idea, startup projects can be particularly expensive and often incur new, unforeseen costs. That is particularly true of technological ideas, which are currently in vogue but require exploratory costs (to pay experts to determine if the idea is feasible) and initial product development costs. Even if a team proves the idea is feasible, they often need to build a working model or prototype to prove that to investors, which can sometimes add thousands of dollars to startup expenses.

Bootstrapped to Angeled_To_Raise_Seed_Capital 1

The vital idea behind bootstrapping in commercial means is to borrow as minimal finance as possible. In two words, you only rely on either on your own budget and savings, on some crowdfunded amount or simply on loans from friends and family. This scenario urges you to borrow insignificant amounts of money and thus keep interest costs minimal. But as the market dynamics populates further, the wider entrepreneurial community starts delivering differing views.

Guy Kawasaki has proclaimed that “you should always be a boot-strapper… too much money is worse than too little” but goes onto to suggest “if you do get offered venture capital, take it, but don’t spend it”.

Most people focus all their time and attention on building their idea, and forget that even the coolest product or service is worthless if people don’t use it. Creating a successful product or service requires two things:

  • A solid implementation of the idea.
  • People that use it.

For the best chance of success, you need to identify the smallest core of your idea that has value to your potential users, build only that, and release it.  This “minimum viable product” or MVP serves as the ultimate idea testing ground.  It lets you build a relatively inexpensive version of your idea, test it with real users, and measure adoption.

Investors see a lot of ideas, which is why they won’t sign an NDA (your idea is not original, no matter what you think). But if you have a team that has delivered products in the past, worked through adversity, and has a failure or two to learn from, then the investor can see a group of people who will protect his investment, and has demonstrated the skills to do so.

So No. An idea will not get you funded.

To be investible, a start-up needs to have a good product-market fit and the potential to scale up quickly to a large market. It needs to be defensible with intellectual property or some other competitive advantage. And it needs to have a credible team in place, people who investors will believe can execute. And there needs to be some kind of proof, also called validation, also called traction.

Building an early prototype also helps you attract tech talent, because it gives people something to look at and play with, and it communicates your idea in a more “tangible” form. Then you can shop it around to potential technical co-founders to get them excited about your vision. If you have the means to actually build a working prototype, so much the better!

Most Angel Investors (and VCs) won’t pay much attention these days without some other sign of traction, especially because the financial and technical barriers to entry are getting lower and lower. Bootstrapped to Angeled_To_Raise_Seed_Capital 2

Additionally, the current market size doesn’t matter. The market size in 10 years is what really matters. You want to be in a small but rapidly growing market. You can change everything in your start-up except the market. So spend a lot of time up front to make sure you’ve thought through your market. “Having value” and “being fundable” are two completely different things.

Two of the most valuable things that the investor community seems to have been seeing from close quarters are: customer feedback and data from pilot research, which can enable them ask questions that lead to product breakthroughs. Angel Investors would need to know how your idea has improved to a bit more than a fledged product wireframe, so that their willingness to invest into those ideas via money, and social reach can increase to ensure that the success of your product is further defines by cutting-edge product development process.

Following guidance is thus seems to have gained ground and immovable traction for all the aspiring entrepreneurs who are progressing from a Bootstrapping channels to Angeled funding:

  • Be value-driven rather than fund-driven
  • Be independent of technologies that make you lose control over your idea
  • Make the customer a base for your product than profit
  • Base your ideas on supply and demand and not on the money it can attract

Once again, this isn’t a strict definition, but the seed round is normally used to fund the initial stage of your company where you’re finding product/market fit, and the following rounds are meant to help with scaling. That said, the road from concept to readiness (aka product MVP) is long and winding. Entrepreneurs’ single greatest challenge in this sphere of activity is balancing bursting creativity with structured, method-driven decision making.

 

Posted on

I am the Product Manager

Of the various hats I have worn all these years – Founder, Sales guy, Deployment Specialist, Level 1 and Level 2 Support, DevOps, Coder, Cheque depositor – I have come to realize I was a Product Manager all along – right from the get go.

Putting a label on what you do is extremely important. It helps you define the job you do, appreciate it, read more on it and helps you improve on that particular skill.

If you are the guy/girl in charge of making the Product among the Founding Team – you are the Product Manager. Say it out aloud – “I am the Product Manager”. The fate of your entire Startup lies in your decisions.

All other designations – CEO, CTO, Director, Co-Founder all are important – for the outside world and your team-mates – but nothing is as critical as the “Product Manager” hat you are wearing now.

Strap the Product Manager Hat tight.

When I gave Sales demo – I was not trying to get a Cheque out of the customer. I was listening to their pain points, and my mind was frantically scanning to see how my Startup could alleviate those paint points. I was trying to find patterns among Customers – so my solution can solve them all. I was trying to see how much value we can give them, and price our product as a fraction of the value ( and not just features ).

When I was paying the monthly bill for AWS account – and saw it was increasing gradually, asked myself – Are such resource hogging servers really necessary – and promptly turned them off – and found better cost effective alternatives. Also when I plan a feature, I keep the cost in mind – I am not going to get sold on the hype of a technology.

When I got a customer to go live – I realised how a few small features created some of the biggest headaches and heartburns. Promptly booted them off or tweaked them.

When I had to do Marketing – do SEO, or write content for Brochrures, or create Competitor analysis – I had to analyse inwardly as well as the competition and could identify the areas we were strong and weak. I knew what areas we could pull ahead of the competition – become more stronger, and what areas we had to improve – so we cannot be beaten down with.

If you are the Product Manager of a Startup – and working 9 to 5, doing a few customer interviews, talking to the CEO/CTO/Founder, browsing competitors website/Apps, STOP – you have to do more. [ ps : Startup founders, if you have hired Product Managers – here is what they have to start doing ]

1. Accompany the Sales guys in a few demos. In fact you should constantly do this – product keeps changing, market keeps changing, competiton keeps changing.

2. Get your hands dirty and deploy a few accounts – from start to finish.

3. Write the next set of marketing material, do the next Competitor Analysis document yourself – instead of just giving inputs.

4. Do SEO, plan the adwords campaign yourself.

5. Be the DevOps and/or pay the AWS bill from your pocket and get it reimbursed – and see for yourself that one cool feature which hardly anyone uses is costing a bomb.

And for Founders of Product Startups – Say it aloud. Print and Stick this in big fonts right in front of you.

“I am the Product Manager”

Guest Post by Venkat Kandaswamy, CoFounder, ApartmentAdda

Posted on

The Product Manager’s RuleBook

The Product Manager’s RuleBook

This post is not about “tools” which will make you (integral)dx more productive. This post is about telling you rules of the Jungle called Product Management.

1-wYnDe5eOdU0UxPD0-KecOA

So you are the Product Manager, Right ?

You just graduated out of B-School (or even worse completed your bachelors degree) and you have been given the product manager tag in the company you decided to work in. Welcome to the Jungle. Unless you have a really f**ed up CEO or a clueless CTO, you are in for a hell of a ride. There are a dozen of definitions of a Product Manager but, here is the one that sticks –

You are the mini ‘CEO’

Welcome to the Jungle. People don’t follow rules here. Especially when it comes to product. Here are 49 rules that I have curated, over the course of 7 years, across Product, Operations and Sales.

Rules

As a Product Manager, you will be exposed to attention, and a lot of it. Mostly unwanted and discomforting. Don’t be surprised if your peers are jealous of your role. You will get pulled into every meeting. You will looked upto/at for every release. For every feature. For almost every client meeting/call. But that is least of your worries. Unless you have been a PM before, your biggest challenge would be not having a benchmark. You have no way to draw the line. Follow these rules and you will stumble less- I am personally still trying to master the art.

  1. Get sold to the product. Believe in the product yourself. If you don’t, try again. If you still can’t make your self believe it, drop it and find something else.
  2. You will get sucked up in your work schedule. Be ready for it.
  3. Don’t get sucked up every time. At times, drop the bomb on Sales and Marketing. Reality check can never hurt
  4. Learn the art of saying no. At least in your head. Practice it over a period of time with/on your CEO, CTO, Sales and Marketing (in that order)
  5. Develop a healthy relationship with your developers, QA and designers.
  6. Avoid making value judgements. What are value judgements ? The statement that you say aloud in your head without ANY authority or reliable data to back it. You always know when you are speaking from the gut. (You know who else spoke from the gut ? George W Bush)
  7. Trust your developers. Back them up. Stand for them. Pat their back and give them credit.
  8. Bet on your Sales and Marketing. Support them. Be their favourite cheer leader. Always
  9. Keep some buffer from Day 0 itself on your delivery schedule. You are surrounded by uncertainties. Every client wanted “it” yesterday and no dev will have it ready by tomorrow.
  10. Split roles between you and your CTO. Decide, who will plan and who will drive the execution. Don’t fuck this one up. Don’t take planning, because you most likely don’t understand your dev’s code.
  11. Between your CEO, CMO and you, figure out who will OBSESS about “organic growth” (SEO). You don’t have bandwidth, don’t ever opt-in for this one.
  12. Coin and propagate your own product terminology/nomenclature, before sales “oversimplifies” it or dev “rocket-sciences” it. This is a critical to build and manage perception.
  13. Write emails with keywords that you can search. Chat with keywords that you can recall and search again. You will spend significant time in forwarding old emails to dev, sales, marketing, CEO. Skip the CTO. Your CTO barely opens your email.
  14. Park your personal choices of colors, fonts and design at home. Product is being built for customer’s delight, not yours (or your investors)
  15. Like a rhetoric, keep telling point #14 to your CEO.
  16. Get a Tee that says “Good is not fast and fast is not cheap.” Boring, cliche but still right.
  17. Pulling an all nighter for product release is cool and fun, but not if you are releasing thrice a week.
  18. Remember that you don’t understand quality assurance or testing. Like everything else, QA is a skill. Unless you have learnt it, avoid claiming it.
  19. If you are building a B2B product, you definitely need a QA. If you are building a B2C product, hell as sure you need more than 1 QA.
  20. Be friends with QA and Designer. Make them feel special. You won’t exist without them.
  21. Assumption is the mother of all fuck-ups. Under communication is an assumption. Hence, under communication is a fuck up. Over communicate and play safe.
  22. Build your own narrative as an objective and data driven person. Understand and question the objective before jumping into anything (including that market research slide for the investor deck)
  23. Document everything that is made and not made. At least try.
  24. Begin you conversations with developers and designers with context. They will feel involved, aware and productive. Context helps. Always.
  25. In the same breathe, demand context from Sales, Marketing and CEO. You will be able to address their requirement faster.
  26. You will always be able to sell better than your entire sales team combined. But again, don’t do it.
  27. Keep your Company Logo Product Logo, favicon, Product Description (1 liner, 5 lines and 1 pager) always ready. Anyone can ask for this. Anytime.
  28. Plan ahead for a week. Do so on a Saturday/Friday Evening. Do it on a Sunday night if you have to but NEVER on a Monday morning.
  29. CEO’s often talk sense. Listen to them.
  30. Not everything that your CEO said was actionable. Don’t act on everything that your CEO says. They most likely didn’t expect action themselves.
  31. Build your own opinion about the industry, domain, and the product. Attend conferences/events focused on your industry.
  32. CTO’s can/will have walls. Be inquisitive ( read pushy)
  33. You need to be aligned with your CEO, Sales, Marketing and CTO. Don’t forget your actual job (Mini CEO/Get-Shit-Done)
  34. There is nothing better than pen paper when it comes to maintaining lists. There is nothing better than pen paper when it comes to wire-framing.
  35. Don’t boil the ocean with every release planning. Every dog has his(/her) day. You will have yours on the day of bug bashing.
  36. Avoid falling sick. Exercise daily. Meditate daily. And buy a Macbook air
  37. Nothing will go wrong if you are late by two minutes late in sending that presentation/ releasing your product update. Be right and late rather than being sorry and on time. If your Sales team can’t hold for a client for 2 mins, imagine..Again, plan better next time and avoid being sorry.
  38. Next time, a Sales guy says that “it was you and your product” that costed him/her a sale. Gulp down your ego. Hear them out. They are ranting. The next day, give it back to them. Patiently.
  39. Your role needs you to seek feedback. Proactively. Ideally once a month, from all your peers. Similarly, your feedback for your peers is critical.
  40. Sales folks are hired for selling. They most likely, can’t make presentations. Live with this fact. Make a template for them. Engage your sales team by changing the template’s colours every 10th week.
  41. There is never a bad time for having chai/coffee. Though Obama doesn’t drink coffee. But again, you are not Obama.
  42. Content writing is NOT your forte. Nevertheless, write the copy for your website or someone else will write something that you never made/promised/planned. Rant about it, if you ever hire a content writer
  43. Create your own reports, dashboards and product performance benchmarks. Do this before the developers starts developing.
  44. Start your day with numbers of the previous day.
  45. Learn to let go, of things you like. Your favourite features, CEO’s favorite feature, colors, fonts, processes and evening dates.
  46. In hindsight, you will always be right. Move on.
  47. You job needs you to be a swinging pendulum. Hah. Self-Pity mode is awesome. But, don’t let it stretch for more than few hours
  48. Last but not the least, remember to laugh about that how, once upon a time, everyone including your head of sales, marketing lead, CEO, CTO and dev ops were clueless about the house of cards that “you” got “built”
  49. In the end, make your own list. And pass it on.

Author – Vivek Khandelwal

Founder of Datability Solutions, a technology startup building iZooto, a web push notification platform for user engagement and retention. 

 

Posted on

Why Your OnPage Chat Is Not Working? [How To Fix It]

Why Your OnPage Chat Is Not Working_ [How To Fix It]

A Step by Step guide on how product marketers should evaluate on page chat tools, implement and use them to start generating leads for sales.

vk1

 

 

We had rolled out the first version of our product in March. It was only in April when we saw a spike in customers signing up and we started getting lot of support enquiries. The reason for the latter was obvious – the product was broken. While we nearly choked on the support requests, we ended up creating a Ver 2 of the product. While the queries continued to flow in, the questions were different. The learning was simple – constant customer interaction and hand holding can prove to be extremely critical, especially when you are driving product adoption. The feedback that flows in, is worth its weight in gold. But again, not every beta user is an email fan and unless you are speaking to everyone ( less likely ), you will potentially be missing out on lot of feedback. It was at this stage, we decided to extend onpage chat as a support channel. The idea was simple – capture feedback whenever you can. And hence started our hunt for drilling down to the ultimate chat tool. We had a very clear requirement – we wanted to talk to people who are inside our product. Nothing more. Nothing less. We played with as many as 7 tools ( we rejected lot many ) and finally drilled down to Drift for onpage chat. I will talk about the choice in detail but before that here is how we went around with our primary research.

What’s Your Requirement ?

We tried a ticketing solution and we failed at using it. Ticketing solutions are meant for dedicated support teams. Back in March, we were 9 people. 3 of us were doing (trying to do) everything. Our requirement was very simple – we were not looking for a blown ticketing solution. At least not yet. But we also identified what we were looking for in the ideal solution –

  1. Query First. Details Later – Most of the messaging platforms, first ask users to fill in a form. These forms can have anything between 1-4 fields. That’s a catchy catch. Situations which trigger support are often desperate. Yes, desperate times call for desperate measures and the user will end up providing all details to log in a support request. The experience is clumsy and far from being ideal. The ideal experience should be the other way round, allowing users to first push their question / query and then asking them for contact details.
  2. Design Centric / Clean UI – Nothing much to say here. The design must encourage user to chat / talk.
  3. Mobile First- The day your product adoption goes beyond 3 times zones, your luxury of operating as per your own time zone goes away. Expect customers to send you emails / chats at hours which would be unearthly for you. You will realise the need to have the ability to handle these chat requests right from a mobile app. Expect your support staff to be answering queries at 2AM, on lunch desk or while sipping chai.

What Options Do We Have – “The List”

First things first – Find the list. Best thing is to go to G2Crowd or GetApp and start from top to bottom. This will save a lot of time. Our first website was built on WordPress, so the WordPress plugin could also be a great place to start your primary research. Not that it’s critical to have a plugin but again it’s a handy. Here are some other places to start your hunt

  • G2Crowd: Live Chat Reviews / GetApp Live Chat Reviews– This can be overwhelming
  • WordPress Plugin – Not a great list
  • Google for – Live Chat / OnPage Chat tools / Chat Based Support Tools. Scan through the first 3 pages on Google.
  • Product Hunt is a great place to search for the newer tools – This can be great because you get on to the Beta list and have access to early bird pricing. Pricing which typically changes after 4-8 weeks ( depending upon the product’s release cycle et al )

“The Free List” – Getting these out of the way

Elimination is extremely helpful, especially when you are hunting for a software and have a couple of dozen options to choose from. There are a dozen free live website chat tools out there. I have always believed that there are no free lunches. These tools come at a cost – user data, limiting experience, weird packaging or dev involvement. I am not saying that these tools are bad. For a business up to a certain scale, free might work. For most, it does not. If you are looking at messaging/chat seriously (Read Here On Why You Should), throw this list out of the window.

Experiencing the Experience

For obvious reasons, all these tools, without fail use their own product for onpage live chat. While experiencing the onpage chat support and talking to sales reps on chat, we realised some key points that influenced our decision.

Live Means “Real Time”. Nothing Else Is Acceptable

 

Onpage ChatUnlike Yahoo chat rooms where users had a lifetime to respond, in case of an onpage chat, the expected response time is seconds. If you are a B2B SaaS product, your average bounce rate ranges between 50% – 70%. Top this up with the fact that the average attention span of a human is less than that of a Goldfish. If your response time exceeds 30-45 seconds, the user has most likely moved on from the page. You have lost a potential lead and valuable feedback. You have to be on your toes to respond to these incoming chats within seconds. This is the real game changer. When you attend a visitor on chat within seconds, you have already won of half of your battle. The rest half is won, when you address their query. Yes, you can’t be available 24*7 but again that’s the idea. You can put together some great copy telling them how you are busy fighting aliens in a parallel universe and are offline but that’s a second option. And you should treat it like that.

Mobile Interface Is Super Critical

Onpage Chat

Because the conversation with the end visitor must be in real time, having a mobile interface for your customer support team / agents is critical. You are strapped out of resources and money to have dedicated agents manning the chat window. It is because of this reason, your Sales / Marketing / Content team should have the ability to reply to these incoming chats – right from their mobile device. This allows them to respond swiftly when you cannot. Imagine being on a client call / heading back home late night / being in the elevator and still converting visitors into paying leads. Most of the tools do offer a dedicated App ( both for iOS and Android) for agents.

Chatting But Only At The Right Time

If you could build an offline store for your product, would you want your sales reps nagging your visitors the minute they entered the store ? If the answer is no, identify simple metrics on when / where / on doing what – you want to prompt your users. These could be basic triggers such as –

  •   Amount of the page scrolled
  •   Time spent on the page
  •   Did a specific action / event on the page

These proxy signals will help you in filtering the spam. Gauging the user’s intent basis some proxies is extremely important – especially when your sales reps will be investing time here.

Getting The Messaging Right

Onpage Chat

More than often, most of the onpage chat prompts that popped up on the website, irrespective of the page had the same messaging. One size fits all approach really doesn’t work. This messaging can be far more personalised basis the history of user or your knowledge about the user – again, something that needs to be done at a later date. Not Day 0. If you were to build an offline store for your product with every page of the website as a full blown section in the store and you had the luxury of having dedicated reps manning each station, how would you like these reps to greet the visitors ? Can this be quirky – Why not. No harm in experimenting.

Smart Conversations with Context

Onpage Chat

In the Utopian world, I would want to know everything about the visitor who I am talking with. Where they are from, which company do they work in, what is their function, what is their objective and so on. Conversations with context are far better than just plain hello. Pick up a tool that allows you to know bit more about the customer. You don’t need to know which other website they are looking at but simpler things like which city they are from – can help your sales reps in break the ice. This is referred to as data enrichment / knowing more about your customer. This can literally take you down the rabbit hole but remember, you don’t have to boil the ocean by knowing everything about the visitor. After all, you do have the option of talking. 🙂

Alright. What Are Your Drilled Down Options ?

Here is what our final list looked like before you apply filters of cost, features, support, API’s, customization et al.

Zeroing In

As a young startup, we follow a simple framework while evaluating third party tools  –

  1. Time vs Value
  2. Effort vs Value
  3. Cost vs Value

The semantics of an early stage startup require the software value to follow the Brontosaurus Curve.Onpage chat

  • Stage 1-  In the initial stage, Founders want to see value without investing too many resources. Stage can be defined as Trial period / Trial period + another month. Once the value is established in the product and support has been evaluated, you are fundamentally good to go.
  • Stage 2 -Post this, the team would put the tool on an auto pilot mode, moving to the next task. Waiting for developer bandwidth to get allocated.
  • Stage 3 -Once developer bandwidth, the next level of value is unlocked. This typically involves personalisation, integration with CRM et al.

Good to have’s at this stage are pre-built integration with CRM, 1 Click Installation ( like a WordPress plugin / Zapier based integration et al )

It is for this reason, we went ahead with Drift. Drift is not a live chat software – it is a customer support and sales tool. Drift’s slack integration is what makes it indispensable for our customer support and sales team. It comes in with a pre-built integration with Hubspot – helping us push and pull data fluently. The fact that it is priced optimally – only helped us pick up the paid version immediately.  Today, 10% of our current leads / signups are because of conversations that our website visitors have with our sales and support team. This number is improving on a daily basis and we are excited about scaling up this channel. Here are some of the handy metrics to be tracked are simple –

  • Open Rates
  • Click Through Rates
  • New Subscribers and
  • New Leads

We @iZooto work hard every week to ensure that we beat our past week stats for all the 4 pointers. There really are no benchmarks besides whatever it is that you have achieved so far. The focus area is simple – to outperform the numbers of last week. Tools in hand – limited dev bandwidth. Access to creative resources for copy and design, followed by sheer execution and constant iteration.

 

Author – Vivek Khandelwal

Founder of Datability Solutions, a technology startup building iZooto, a web push notification platform for user engagement and retention. 

 

 

Posted on

The Need for Product Thinking and Successes

“The role of a product manager is to discover a product that is valuable, usable and feasible.” – Marty Cagan, Partner, Silicon Valley Product Group

In a few simple words, this quote capture the essence of what this article is all about.

At a recent conference with several venture capitalists, product managers and executives from both corporates and upcoming start-ups, one of the VCs in the room asked, “212 Indian start-ups did not survive 2016. Investments plunged by 44.3%. VCs have started reviewing their investments closely and are being stingier when it comes to spreading their money too thin. How will you convince us and other stakeholders about your product and ensure that it succeeds?”

The answer lies within the approach to product management. Think about it! The lack of an efficient approach to product management is the root cause of start-up failure. Through a systematic approach, you can detect early enough what projects are likely to succeed in the long-term, and invest your time and money more wisely – as compared to investing in several short-term experimentative projects. This is the strategy employed by successful product companies, and if you look closely, a pattern tends to emerge in the practices employed by the best product managers, and these are:

  • Inside-Out Thinking Is a Big NO-NO
  • Building Long-term Sustainable Vision, Innovation & Roadmap
  • Evidence Or Insight-Based Decision-Making
  • Let’s deep-dive into these practices:
  • Inside-Out Thinking Is a Big NO-NO

Our existing products are a success -> The executives who built these products have an intuition that the new product is the next big thing -> Therefore, customers will definitely like our new product

This the basis of Inside-out thinking where the wrong reasons are used to decide which products should be invested in and developed. Some of the common inside-out situations are intuition that a product will work, pressure from CEOs, the assumption that customers don’t know what they want, the feeling that the product will definitely sell and so on.

It’s a clear violation of what we call the First Law of Product: Customer decide what products they like, not companies.

The best product managers employ customer-informed decision making and see these situations as warning signs when it comes to making product decisions.

Building Long-term Sustainable Vision, Innovation & Roadmap

A great product roadmap is a Product Managers’ secret weapon. Product road-mapping works best when you start with a long-term vision and strategy, prioritize the product itself over the features, and manage ideas smartly.

Not having a long-term visions and strategy is the fastest route to product management failure. All great roadmaps start with a vision and a strategy to achieve that vision, which keeps the various teams invested in the same shared success of the product.

Next is prioritization. One needs to prioritize the product over features. One that’s done, certain features need to be prioritized over others. It’s not that features aren’t important but that they are often secondary to the reason a customer or user buys a product.

Lastly, being able to say “No” is extremely crucial to developing a successful product. The best product managers are excellent at managing new ideas that come from the various stakeholders involved. There is no shortage of new and innovative ideas, and the best product managers know whether these ideas roll up to their product strategy or not. They consider all ideas, rank them against the product strategy, make a decision to employ them or not, and keep everyone informed about the “why” in their decision-making process.

Evidence or Insight-Based Decision-Making

A key component that successful product managers use to drive the product team forward with insights. This is critical because they help validate that the team is pursuing the right course of action. With real-world user data, customer feedback, and metrics on the product, one already has an excellent source of business intelligence to make the best decisions for the product. When asked why you’ve selected one direction over another for the next iteration of the product, your ability to present a compelling explanation backed by real data will go a long way toward earning everyone’s buy-in.

Key Takeaways

  • Every product organization will save significant money by investing at the right time for the right product initiative
  • End-to-end vision, planning and execution processes will differentiate product companies in the market place
  • A systematic approach to product road mapping and management drastically reduces the risk of product failure
  • Gathering valuable intelligence and insights from various stakeholders, customers and the market will go a long way in defining the success of your product.
  • The harsh reality of 2016 might just be the wake-up call that the start-up world needed, and our prediction is that 2017 is going to be a great year for Indian start-ups!

Guest Post by Mr. R.N. Prasad, Consultant at Manipal Global Academy of Information Technology (MGAIT). 

He comes with over 35 years of Enterprise IT experience. He has served various IT giants like Wipro, Satyam, IBM, INNOSOFT and Infosys in leadership positions. In his last corporate engagement, Mr. Prasad was the AVP, Education and Research at Infosys, and was heading the Business Intelligence and Analytics Practice. His other areas of focus and expertise include IT Product Development Management, and IT Strategy Consulting. Mr. Prasad is a Harvard Certified “Teaching for Understanding” practitioner and a Franklin Covey Gold Certified 4DX Coach.

Posted on

PAY-IT-FORWARD PARADOX… The More You Give, The More You Receive

PAY-IT-FORWARD PARADOX… The More You Give, The More You Receive

Ever noticed how the busiest of people are often the ones that find time more easily than others?

It is about making the time versus having the time!

When you make time despite busy schedules and packed days to share your experience and perspectives it helps so many people, definitely more than you could individually imagine. In the process though, you get so much back, more than you could individually imagine. And, I am not just talking about the ego boost you get from your audience, it is the whole process. Deciding what to share allows you to spend time reflecting, perhaps even researching. You learn and remind yourself of what you knew and could have forgotten. The prep certainly helps you articulate and verbalize your thoughts. When you hear your audiences’ perspectives, another learning opportunity. When you get asked a question you couldn’t answer at first, yeah, another learning opportunity. It is the gift that keeps on giving. You very quickly see that making the time to share your thoughts and experiences is a really good way to learn.

At Pensaar, we are crazy biased towards design thinking as a mind set and a process to innovate.

We are practitioners and have used design thinking in our own jobs to innovate and are able to share war stories, trials and tribulations from our experiences. Being less than 6 months old, this August we took on the arduous task of putting together the Design Thinking Summit. The first draft was a vision more than a plan. Here’s what was serendipitous… as we shared our vision, many good people came to support our vision.

NSRCEL-IIM Bangalore, Intuit, iSPIRT and YourStory gave us their support. Many friends and fellow practitioners gave us their time, ideas and mentorship. What was the result? 70+ people went through a 3-day experience of applying design thinking to a real problem and 250+ people spent 1-day in large discussion formats learning about design thinking from each other.

It was truly inspiring and motivating to see so many people pay it forward, we were blessed to have that kind of support. Gave us more passion and energy to realize our vision to spread the awareness and application of design thinking.

Paying-it-forward is wonderful but then you imagine doing that for a bunch of people you have no vested interest in, it is pure humility.

The magnanimity with which they approach knowledge sharing is humbling. There is recognition of the notion that there are millions out there waiting to interact and hear their encouraging and inspirational stories. We asked a few design do-gooders we have had the honour of working with about why they work pro-bono. Here is what they had to say… we are indeed grateful to all the pay-it-forward individuals, makes us want to do more!

“One of the most wonderful experiences in life is to see an idea evolve into a feature or a product and then into business. There are a great many ideas out there that are ready to take this journey. Helping others navigate and experience this journey is what addressing larger audiences is all about” Tridib Roy Chowdhury, GM | Sr Director Products, Adobe

“I do it to pay it forward to peers, practitioners, designers & society at large for better ways to solve problems by design thinking. It is great to be part of something, where it is not driven by the idea of an individual but as a collaborative effort for change.I also get to be part of a platform where I can exchange idea/thoughts/ methodologies and more importantly learn, since there is no single right/wrong way to do design thinking” Harshit Desai, Design Thinker | Digital Transformation Lead | User Experience Strategist, KPMG India

“I see two extremes in the practice of Design Thinking. One pretty serious and offering the best for innovating for better lives. The other is lighter and sometimes belittling the practice. I am a pure play Design thinking practitioner and like to spread the message that for some DT is life changing and for some it betters lives. I have been part of such experiences. It is inspirational! Whether it is pro-bono or not I have been doing this for some years and will continue to do so, to reduce the negativity about design thinking to my best possible ability” Lakshman P Seshadri | Strategy | Innovation & Design, SAP

“Success for individuals or organizations is about what we can do for others as well. I consider it valuable to make the time to share knowledge. Empowering outfits and individuals is just as important. Pensaar’s mission to evangelise and spread design thinking at a nascent stage ties into my belief of sharing is learning” Venkat Kotamaraju | Growth & Strategy Leader, Pensaar

The joy in knowing that that they are changing lives is what makes evangelizing the methodology so important. Also, it triggers a beautiful snowball effect of only inspiring others to do the same.

Guest Post by Deepa Bachu, Pensaar 

Posted on

Product Manager as the Wicket Keeper

Wishing you all a very happy 2017, may you get the guts and courage to make the change this year.

Mahendra Singh Dhoni, one of the most successful cricketers is certainly an inspiration for all of us – cricket fans and Indians. While he is a famous and winning captain, probably being a wicket keeper has helped him to shape up his instincts, strategy and execution.

Being a product manager for few years now, I often relate to being a wicket keeper, who really wears multiple hats to help his team and win in the market. Often there is lack of clarity on the role of a Product Manager and why are they needed. In this post I would like to focus on drawing some parallels between Wicket keeper and Product Manager , especially differentiating the greats from good ones.

Pitch reader (Market)

Understanding the pitch is a key aspect to winning a cricket match – so is the understanding of the market to win with a product. Wicket keepers are great pitch readers, as they stay close to it always. So is the product manager, as understanding the market is a very significant success factor for products. If product managers can read the pitch (market) well, they can certainly guide the team very well to shape the right product that fits the market.

Supporting the bowler (Development)

One of the primary roles of product managers is to work very closely with development to shape and release the product. They are involved every ball, they need to be attentive to every detail, they need a great presence of mind, they need to keep motivating and appreciating every milestone. They also support the bowlers on field placements – read as key reviews of every aspect of the design of the product. They can give instant feedback and suggest changes, on the spot to ensure success. They also catch to take wickets – similar to some key contributions by product managers on prototyping and closing loop on the product.

Alert with fielders (Quality Assurance)

Wicket keepers stay alert with fielders and set an example in the field, as well as guide the field on what’s coming from the bowlers. Product managers similarly are one of the initial quality assurance /testers of the product, and guide the QA on how to ensure the quality of the product.

Close to opponent (Competitive insights)

Wicket keepers stay very close to the opponent batsman. They know whats their strength and weakness by closely following and watching them. This can certainly help share their insights to the bowlers. Similarly Product Managers have to stay very close to whats being done by competition, and how the products they build can surpass the competitor products, by understanding their strengths and weakness.

Handy batsman (Sales)

Finally wicket keepers can also support with the bat. While they are not the strike batsman, they may be useful handy batsman as they know the pitch and the opponents, and in some situations could single handed win with their extra batting abilities (like a Dhoni or Gilchrist). Product Manager similarly can support Sales to win in the market. Product managers know all the details of the product, the market and the competition – so they can certainly help win in sales. While they are not the strike sales man, they can be an effective supporting person for the striker. Some Product Managers have a very high success rate of closing business when they are involved.

There could be more parallels…but hope the above helped you understand the critical role of product manager, as critical as a wicket keeper in a cricket match, and some of the key ingredients and potential contribution they can make to your product.

When we all started playing (read startup), we may not need a full time wicket keeper as someone wears that hat in rotation, but to make it big (beyond early stage startup) you probably need one.

Great Product Managers move on to become Great Product Leaders and are winners….Adam Gilchrist or our MS Dhoni !

PS : Never thought MS Dhoni will resign captaincy when i wrote this blog post (he resigned on same day when this post was published). Anyway hoping he will continue to be a wicket keeper for a some more period, and great team player 🙂

Update on 15 Aug 2020 : M S Dhoni retires from international cricket, and the above post is a reflection of how his skills, or skills of a wicket keeper is so important, like how a product manager would contribute to a product !

Posted on

Minimum Viable Technology (MVT) — Move Fast & Keep Shipping

Technology teams can be the biggest asset or worst bottleneck for a growing company based on the strategy taken by them. In name of future proofing engineering, the technology teams become a hurdle to company’s goals. You can see the ‘hidden frustration” in Bezos words below ..

Engineers should be fast acting cowboys instead of calm clear-headed computer scientists — Jeff Bezos, Founder & CEO, Amazon

Rampant Problem in Industry: When the task is to build a bike, the product and technology teams would plan for a product, which can later run on motor, seat four people, sail in sea and even fly in the future. This hypothetical building of castle in air, digresses the focus from the real problem to be fixed. This is what Bezos is suggesting to refrain from, as it wastes resources and agonizingly delays the time to market.

Being defensive, the Product/Technology teams usually build a cannon for killing a bird.

Minimum Viable Product (MVP) philosophy evolved, to avoid this “unnecessarily over-thinking and over-preparation” problem which plagued products in all companies. It encouraged building the minimum required at a certain point of time and then iterating and improving it going forward. MVP approach enables much needed fast experimentation, fail fast and invest where needed strategy.

No such philosophy evolved for Technology. Therefore, the decades old defensiveand paranoid philosophy still prevails (which was much needed during older 1–2 year long waterfall releases). This becomes competitive disadvantage for startups usually fighting for survival or growing fast.

Fundamental problem is that the engineers blindly copy the large company’s strategies, considering them to be the standard. Corporate and startups differ widely on their needs of scale, brand, speed, impact of a feature, loss by a bug, etc. Startups enjoy more freedom to make mistakes and that they should exploit to their benefit.

Strategies used in big companies are more often irrelevant and even detrimentalto a small growing company’s interests.

Minimum Viable Technology: The solution to above problems is to Build the Minimum Technology, that makes the product and its foreseeable further iterations Viable. Make it live a.s.a.p. and then iterate and improve it based on real usage learnings. Every company is in different stage of evolution. Something that is MVT for a big company, can be over-engineering for startups.

If the task is to kill a bird, we should build a catapult/small-gun to begin with. If that becomes successful and there is a need to kill more or bigger animals, then bigger-guns/cannons should be built as required.

There is nothing so useless as doing efficiently that which should not be done at all. ~ Peter Drucker

Startups experiment a lot and only a few of them sustain the test of time. As per 80–20 rule, only those 20% successful ones should get deeper technology investments.

Principles of Minimum Viable Technology (MVT):

  • MVP + MVT + Agile is the complete package.

MVP is for product scope minimisation. MVT is for technology scope minimisation. Agile is for iterative technology execution.

  • Most decisions can be reversed or fixed easily. Choose wisely by bucketing the decision properly into reversible or non-reversible. And judiciously decide how much to prepare for that case. (Read Jeff Bezos’ two types of decisions).

It’s important to internalise how irreversible, fatal, or non-fatal a decision may be. Very few can’t be undone. — Dave Girouard

  • Build MVT — Fast & cost effective. Build the Minimum Technology that makes the product and their foreseeable iterations Viable. Prefer operational familiarity while choosing technology. Don’t fall for the latest buzzword (sure sign of inexperience).
  • Refactoring is part of success plan: Getting to refactor is a sign of success. Only components which are used and evolve fast; become complex overtime and need to be refactored. Be ready to re-factor or throw away and rebuild where justified.

The best code you can write now is the code you will discard in a couple of years time. – Martin Fowler

  • Think long term, act short term: It’s a fine line between under-engineering and MVT approach, that has to be tread properly. Don’t rush into execution without thinking completely, otherwise it will lead to more resource waste later. Thinking has to complete and deliberate choices must be there to cut scope. The rule of thumb, is  discuss the ideal solution on board and then decide what to take out of scope to make it MVT.
  • Speed and Quality must go hand in hand: Never justify the bad quality of your work by using the speed of execution as excuse.

MVT is for scope reduction, not for quality reduction.

  • MVP/MVT is applicable for every iteration/release: People relate MVP to the First release of product only. In fact, it applies to every stage. MVP/MVT needs to be chosen from the remaining next tasks at every stage. At no stage, it is ok to waste time and resources.
  • Deep understanding, conviction and confidence is needed for MVT. Both MVP and MVT approach is about taking bold calls like — “Out of these tasks, only this much is enough to win this stage of game”. While defensive traditional approach is like — “we can’t win or sustain if we do not do most of the known tasks”.
  • Alignment across departments is must for MVT execution. MVT reduces time to market in 80% of cases, by focusing on the core of what is needed. As per 80-20 rule, only 20% will need re-factoring and re-architecture later. Due to mistrust and friction between departments, they keep looking for faults in others. This leads to engineering (and others) being defensive and therefore over prepare to avoid any mistakes. This is explained and solved in Solver Teams post. In ST approach, all parties are in hot sync and are aware of trade offs taken while executing. So there is strong understanding and support for such efforts.

Move Fast. Keep Shipping!!

* The term “Minimum Viable Technology – MVT” is coined by the author – Ajay Shrivastava

Posted on

The specifics – How we grew 100% organically every quarter 

We had earlier written about the fundamentals that helped us in growing over past one year but recently we looked back to dig further and list down few specifics that we believe helped our growth. These come from our own experience as a consumer company and might not be applicable to every startup but we hope that something applicable and actionable is derived from the points below.

the-specifics-how-we-grew-100-organically-every-quarter

What we did:

1) We operated below scale in a very patient manner (Do things that don’t scale — Paul Graham)

Early on, we saved contacts of all our top 300 active users in a company phone and spent a great deal of time in assisting them, reaching out to them. We called them all at least once a month, interacted over WhatsApp and staying tuned to their feedback helped us iterate our product at a faster pace. These users were also the ones whose feedback we gave primary weightage to. The idea was that it’s better to have few hundred very satisfied users than few thousand dissatisfied users.

This further helped us in a subjective product validation as we monitored NPS (Net Promoter Score) and gauged how disappointed they will be, if we took the product away from market.

2) Almost everyone in our team did customer support early on.

Over a period of time, many customers thought that we had a big team of customer support staff while the reality was that anyone would pick up the phone kept on the table in the early days. Reason for this was that, we wanted to listen to every piece of feedback ourselves and understand the issues users faced. The same set of issues and appropriate actions to be taken differed in many instances when viewed from different perspectives of development team, marketing team and product team.

The idea was that we need to have high capacity of attentiveness. We would respond to every tweet, call, email and resolve any issue within 10 minutes. This further reflected in our play store reviews where a vast number of them praise our customer support.

This non-scalable approach is an advantage of being a first mover in the market, the tacit knowledge acquired is invaluable and sets up time compression diseconomies (an MBA jargon for first mover economic advantage) that just can’t be overcome overnight by a clone.

3) We sold like a non-tech company!

Remember those users whom we had on our WhatsApp, we cross-sell and up-sell a lot of different use cases to them by just picking up the phone, so much so that they started recognising us by our voice over phone. We did a user specific profiling of their spend and the use cases they spent on and carried out over quarters weekly and monthly comparative analysis to predict growth trajectory and fine tune our throttle accordingly.

We were obviously not selling penny stocks but genuinely helping them out!These users further spread the word about product among their peers and we started mapping behaviour of incoming cohorts of users.

4) We iterated very fast for a focussed outcome

We have very short product release cycles to experiment and test our hypotheses and improve funnels conversion and KPIs. As a small startup, we realised that at any point of time, there are maximum of 2 metrics that we can focus on.

This ensured that we learnt and acquired knowledge of our social payments domain on a regular weekly basis and this growth is the kind that doesn’t reflect in vanity metrics like app downloads.

5) We maintained sanity when it came to data

We tracked but never over — analysed data. We largely relied on user observation and subjective feedback in early days and later ensured that the assumptions we test are based on decent sized cohorts which are statistically significant. For user observation and feedback, 10–15 users at a time is usually a good number to uncover majority of issues or problems a user would encounter.

6) We started with a clean slate with no prior bias.

We believe that there is nothing ‘standard’ about standards or best practices which is why we put out the disclaimer upfront that our learnings might not be relevant and applicable to all. For a unique product play and especially if you are not copying a product from the West, one requires patience and has to test everything about the product.

We iterated our product with constant user feedback and observation improving the conversions within the product and engagement.

We also got some validation for our approach towards very unique challenges we faced. One such example was partitioning our app in two parts — ‘Split n Settle — Post Transaction money settlement among friends’ and ‘Plan n Pay — Pre Transaction collection among friends’ and the approaches we took were also seen in products whose UX we admire like ClearTrip, Tinder and Google Play.

We have just begun and are learning something new everyday. It is this process of never ending learning from consumers while serving them, that excites and keeps us going on every day.

Guest Post by Ankit, MyPoolin

Posted on

Is your product stuck with biased feedback?

Product Management be it for Internet world or otherwise is an interesting job. One gets exposed to multiple business functions be it marketing, sales, customer support or general management. The only result that is desired from Product folks is to ship a product that users will love and then it should have a network effect — i.e. other associated functions can be almost on auto-pilot.

launching-pune-chapter-of-iken

Alas, getting to this single point result is easier said than done. Success for product can be attributed to multiple factors however having been into product space for quite some time, a critical reason of product failure can definitely be attributed to BIASED feedback.

Given below are few biased factors that a product should not fell upon but is not able to avoid it –

a. Internal Bias — A product team almost on a daily basis works on wire-frames, prototypes and on developing actual product screens etc, a product marketing team works on a daily basis on new acquisition and awareness strategies — landing pages, ad words etc. and a product sales team (if any) would work on refining sales pitches, making decks etc. However when it comes to getting feedback on the work done, it is mostly either the internal team or managers.The internal team members or managers are the first one that introduces bias in the product. The internal folks are so much breathing the product that after some time, fresh perspective is not visible at all.

b. Data bias — Yes, tracking user data on product usage is a gold mine however how one goes about interpreting the data can again lead to a biased solution. For instance, you identify that a feature is not being used at all, a biased conclusion will be to remove the feature and mostly that is what a product team generally do. However, a feature not being used can also be related to non-understanding of it by users during the transaction journey or perhaps not enough push by the marketing team? Can the same feature be presented in a different manner? This will or rather cannot be uncovered by data.

c. User Bias — Most of the products have one or more ways to solicit feedback from product users. However, what I have found is that a typical feedback process generally will not point to real pain points of a user. This happens because a user is not equipped to describe the pain point in a way that a product team can understand and thus sometimes what users say and what they actually want can have a huge difference

Based on my experience, the best inputs I have received for my product has always been from folks who are from similar functions but not in the same organization.

What has been your journey to ensure product doesn’t get stuck with biased feedback?

Guest post by Nishith Gupta, UXHacks

Posted on

Product Owner and/or Product Manager – Don’t Debate the Wrong Issue

Recently I was called into a mid-size software organization – and got right in the middle of a heated debate that had obviously been going on for some time. Development wanted to move to a Scrum-like agile model, and put pressure on the established Software Product Management (SPM) department to change their name to Product Owner which SPM refused vehemently. Development argued that the agile terms had to be used as symbols for the cultural change to a faster organization that the company executives were aiming at with the move to agile.

product-manager-dont-debate-the-wrong-issue

Everybody was appalled when I told them that they were discussing the wrong issue. Yes – terms can have psychological impact. But to make the organization really faster first priority has to be on processes, methodologies and a corresponding role model. Once these are sufficiently improved in line with the organizations‘ objectives, tasks and capabilities, you can agree on new names if you want to. Development argued that they did not want to waste time with these discussions since Scrum already defined processes and roles. Now I disagreed.

Scrum as defined in the Scrum Guide is just a framework that requires significant customization for any real world implementation. In fact, the majority of organizations do not even implement all the must-have elements of the framework, but then still claim to do Scrum. That is in particular true for the Scrum roles as is nicely documented in the State-of-Scrum Report of the Scrum Alliance (see http://bit.ly/1C391MK, pp. 22-23). I would not be surprised if this picture stayed quite the same in the report’s update to be published later this year.

The product owner role is defined as a member of the Scrum Team that feeds the team continuously with work in the form of user stories based on the prioritized requirements in the backlog. The product owner is the interface to the outside world, the rest of the team is shielded so that they can focus on their development work with optimal productivity. Implemented like this, product owner is a rather operational full-time role whose tasks overlap with a software product manager’s in the areas of requirements engineering and release planning.

This overlap needs to be sorted out in terms of process and role definitions. Some Scrum consultants claim that the most productive solution is one person who assumes both the product owner and product manager roles and all tasks attached to them – which they call – guess what? – product owner. Well – unfortunately wishful thinking for most organizations! This may work in some environments with one Scrum Team, but it can definitely not scale up. And the poor person who gets this combined product owner/product manager role will always be pushed by the team to prioritize her/his operational tasks. Over time the more strategic tasks are neglected – to the disadvantage of the product and the organization. Alternatively, operational tasks can be delegated to other Scrum Team members, but that boils down to an implicit split of the two roles again.

Don’t get me wrong! I see a lot of value in agile in a lot of situations, but it needs to be customized in the right way. In the end, my customer decided to have two roles – product owner and product manager – strongly linked for optimal communication, but with clearly defined different tasks and responsibilities. And it works – faster.

I will be speaking on this topic at ISPMA webinar on 4th November at 2:30 PM IST. You may register here to attend the webinar. I would request you to ask any questions you have on the subject. I would be happy to answer.

Guest Post by Hans-Bernd, Chairman at ISPMA.
Full disclosure: I am CSPO (Certified Scrum Product Owner), ISPMA Certified Software Product Manager, and Board Member of ISPMA (www.ispma.org).

For more details regarding Upcoming Webinar on PM Vs PO, click here.

Posted on

Is your user story really about the user?

Once upon a time, in a land far, far away, lived a grumpy old wizard who loved spending time throwing stones at little kids who played near his mansion…

is-your-user-story-really-about-the-user

In just a few words, good stories transport you to a different place, stoke your imagination & involve you in the life and activity of someone you don’t know about. Almost immediately you begin forming an opinion about the key characters.

I love stories.

I was very excited when I first came across the term user story in Agile. This was not a user interaction, or a user feature. It was a story.

Ideally, the story would describe the user, his/her context, problem and gratification. It would make the user alive to the team trying to help him.

Sadly, from what I’ve seen across companies, not many user stories are written well.

Badly written user stories either have generic description of the user of the product, or end up being feature specs (eg: As a user, I want a green button labeled ON)

There are usually two reasons for bad user stories:

  • The product owner doesn’t know much about the user and/or
  • The engineering team treats the user story as a specification document

The user story should describe what the user wants to do. Instead, it ends up being whatyou want to do for the user.

Product owner and user research

I had earlier written about Agile as a concept vs. Agile as a process. A key limitation in treating Agile as a process is that the product owner is driven by the engineering team.

The key determinant is to keep the engineering teams executing, so the product owner ends up spending a lot of time ensuring the backlog is filled up in advance. This leaves little or no time for understanding the user.

Constrained by time, the product owner makes a generic outline of the user and anchoring stories around this.

If you treat Agile as a concept, the product owner is supposed to represent the customer’s voice in the development process. The product owner has to know his user’s needs well.

Many product owners, especially in B2B scenarios, end up figuring out user needs through secondary research, or based on quick conversations with a couple of target users.

Nothing is more dangerous (in the Agile environment) than a product owner who has limited knowledge about the user, but considers himself a representative.

Why?

Because the team ends up building a product that no user may end up liking. During the development process, the product owner argues eloquently about user needs, often mistaking that his/her view concurs with the user’s view. In the end, the product owner is satisfied with the product; no user is.

Users in real world often surprise you. If you’re in tourist mode, you often end up with the wrong conclusions.

I was once involved in building a mobile app for a low-end phone. I asked the product owner to draw some outlines of the user’s constraints and needs. When we reconvened, he came up with an observation that users were not bothered with data costs. “After all,” he said, “what difference does Rs. 10/- make to the mobile bill?” He was basing his argument on a chat with a couple of users across stores and one store employee.

Many of our target users were on pre-paid accounts, and rationed their mobile usage. They had dual SIM phones, and kept one slot for switching carriers who gave better deals. They would route incoming to the fixed SIM, and keep swapping the other SIM based on carrier packages where they could save money.

While we didn’t go about doing a detailed user study on this, I was able to cull information by speaking to a few college students, who were part of the TG, and triangulate it with information from friends who worked at carriers.

In this case, Rs. 10/- was an inconsequential amount to the product owner, but was a huge consideration for the actual user. If we had ended up missing this, we would have built a product that users would quickly have rejected due to high data demands.

Many engineering teams, especially those transitioning to the Agile mode of working, often insist on the user stories being complete, i.e. specified so that they can efficiently code out the solution.

This results in the product owner spending a lot of time writing and rewriting user story descriptions and acceptance criteria. As development progresses, the story backlog ends up having a lot of technical stories, bug descriptions and engineering terms. And in the process, the focus on the user’s problem is lost.

Ideally, a user story is designed to enable exploration of different ways of solving a user’s problem. It describes what the user wants, and a context in which s/he feels the need. The constraints are written in the acceptance criteria.

Given this, the technical team & designers can now explore multiple ways of solving the problem. The product owner can stay involved to judge which of the solutions serves the user’s need best.

In this approach, the team retains its flexibility in thinking up new ways of solving problems, often discovering better solutions than a didactic way of the specifications written by the product owner.

Of course this isn’t easy. It requires a lot of planning ahead to ensure there’s time for the exploration. It also needs maturity from members of the team. The team has to be comfortable that some of the work they do will be thrown away as they discover new solutions, and not stick solely to efficiency metrics.

Some organizations follow a dual-track method for Agile for this: a delivery and a discovery track. The discovery track is usually a small team that handles the experimentation. These solutions are often quickly tested with real users for quick validation.

One of the best ways I’ve seen to get out of the user story as spec is for the team to decide at the start of the project that they would keep a couple of experimental sprints, where they try an exploratory approach to build a solution based on understanding the user’s context without detailed specifications. Many times, these end up sensitizing the development team to the user they build for, enabling them to think for the user instead of thinking for the project.

One of the key beliefs in Agile is to know the user well, and build a product s/he likes. In my experience, I found that this often is key to building a great product.

I’d love to hear your experiences with user stories in the comments below.