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!

Transforming a nation with products

India is at a crossroads today. Gloom has replaced what seemed to be an unending boom just a few years ago. After a decade of rapid growth led by the services sector, the Indian economy has hit a plateau. While services exports continue to grow and create a surplus in services trade, they only constitute 35% of the country’s total exports and are unlikely to compensate for the deep deficit in merchandise trade that stands at 10% of gross domestic product (GDP). This deficit in goods trade is partly attributed to the services-led route of economic development taken by India in the post-liberalization era, in contrast to a manufacturing-led route to development that creates a strong base for goods trade.

From a national policy perspective, excessive dependence on services is akin to putting all one’s eggs in the same basket. For a country of India’s size, diversity, and global aspirations, a more diversified economic basket is an urgent imperative.

The current situation has created a need to nurture and bolster “products” or “goods” industries. But the challenging question is where to begin, and which industry might lead the charge. Given India’s rise to prominence in the last two decades as a software hub, could software products be the ideal place to start?
Unlike manufactured products, software does not need major logistics infrastructure, nor does it depend on inputs other than human capital. Further, software products can be delivered through the cloud.

Therefore, the software product industry holds the potential to circumvent India’s relatively weak position in manufacturing and yet capture a high enough degree of value to address at least some of our economic challenges.

In addition to the direct benefit of a healthy software product industry to the national economy, technology can bring about an order of magnitude improvement in the effectiveness and competitiveness of other sectors, be they industrial or social. Industries as diverse as healthcare and jewellery could benefit from standardized software applications that enhance their competitiveness. Therefore, a competitive software product industry will not only benefit the economy but will have a ripple effect across the society at large.

Though the aspiration for a vibrant software product industry is compelling, international comparisons show that we have much ground to cover. While the number of engineers in the Israeli software industry is only a third of those employed in the Indian product industry (including MNC captives), Israeli start-ups raise almost double the amount of venture capital that Indian start-ups do. Further, we have thrice the number of start-ups as Israel, but Israeli investors managed 40 times the number of exits compared to Indian companies in 2011. So far, India’s software product industry is punching below its weight category and needs a fillip.

In the past we have failed to realize our potential in products. Take telecom as an example. We have created mobile services giants like Airtel but have no telecom product industry to speak of. Our air force is one of the largest in the world and yet we haven’t been able to get the light combat aircraft (LCA) deployed in 30 years. We have somehow not been able to develop a product industry in India.

A challenge as big as this one is unlikely to have a one-shot solution. Yet, a vibrant product industry is unlikely to emerge by chance either. The solution needs to emerge gradually and iteratively, based on a continuous dialogue between software product companies, investors, policy makers and potential customers. Shaping policy, funnelling investments and stimulating the market can potentially steer the software product industry in the right direction.

This article first appeared in the LiveMint

Drinking from the firehose at iSPIRT PlayBook Roundtable (on Effective Product Management) at Delhi

When nearly two dozen product enthusiasts sit around a table passionately talking for 4-½ hours, expertly addressed by two product veterans – Amit Somani and Amit Ranjan, you can expect an information overload. And, it did seem like drinking from the firehose, trying to capture all the takeaways in the intense back and forth, where even a tea-break seemed imposed. A blast it was – this iSPIRT Playbook Roundtable Delhi edition on “Effective Product Mgmt & Delivery”, focused around learning for startups.

[This was the NCR session on Apr 13th. Initiated, as part of iSPIRT, by Avinash Raghava, and very ably facilitated & supported by Aneesh Reddy. Great facility and great Food by Eko Financials. Thanks guys, Awesome effort!!!]

iSPIRT Playbook Roundtable in Delhi (on Flickr)
iSPIRT Playbook Roundtable in Delhi (Click to see all on Flickr)

Thankfully, there was a structure, laid out initially across specific dimensions – Product Planning, Delivering, Hiring, Culture, Metrics, Customer. These themes kept repeating through the session with questions coming from participants across the breadth & depth of product management, and many times touching upon all the aspects of running a product company.

Here’s an attempt to sum up the takeaways from this long & exhaustive (not exhausting, yet!) session.

Planning & Delivering the Product

–       Product Planning in many start-ups is not an elaborate exercise. It is typically handled by one of the founders, and “build and adapt as you go” is the norm.

–       Delivering a great product is always an intersection of Engineering, Design and Product Management, with Product team in the driver’s seat. This intersection and collaboration is one of the critical factors in getting a great product delivered.

–       Getting the Engineers and Designers to collaborate is one of the key challenges. As per Amit R, what helped them at Slideshare was the fact that they always hired Engineers with a flair for Design. A great developer as part of the product team is 70% Engineer & 30% Designer, as per him.

Product Metrics

Amit S emphasized that metrics are very important for product managers. When the team grows (when you can no longer rely on people to just talk to each other and get things done), the metrics-driven product management becomes critical. Touching upon the right hiring in this context, Amit S insists on covering the candidate’s thought process around metrics (with open questions such as – what would be your primary metric if you were designing the Delhi metro).

Metrics & the Rule of 1/1/1: This is one rule around metric that Amit S follows. What will be your metric for 1 Week, 1 Month, & 1 Year. Break it down, with crystal clarity and follow it up religiously. (A great resource for B2C space around metrics is a presentation by Dave McCleor – Startup Metrics for Pirates).

Some learning around Metrics:

–       It is important to be clear of the vision, and how it connects to the primary metrics that you define. There’s a direct correspondence between identification of the key metric and the clarity of what the product is trying to achieve.

–       Relevance of the metrics to the specific goals through the product journey is important. As one goes along in the product journey, the dimensions on which key metrics are identified may vary. Initially it may be customer acquisition; And then it may be engagement; then conversion; retention; life-time value; and so on. 

All attendees at the Playbook roundtable iSPIRT Playbook Roundtable in Delhi

Customers

One of the key questions around customer aspect of product management is – What is the right spec for the product? One of the biggest mistakes product managers tend to make, as per Amit S, is when they confuse the “Customer Requirements” with the “Product Requirements”! Sorting this out is the core to the responsibility of a Product Manager.

Some of the tips & tricks around Product Specs:

–       When faced with a requirement, the first pass criterion (in B2B scenario) should be – if the requirement is relevant to at least 3 customers.

–       There are various tools to interact with customers, and get feedback: Surveys, Net Promoter Scoring, Feedback through the product interfaces, and so on.

–       Get the Information from Customers, Tone it down, Tune it further, and then arrive at the specs for “Engineering”.

–       What should the spec typically look like? Default Rule of Thumb – 1 Page Spec. It should be very focused, very clear, in what the feature is trying to achieve, and at the same time not too long.

–       A Good quality spec considers the “Least Granularity of time” with Clarity of thought. That’s from the Project Management perspective.  From the functional perspective, Amazon has a good model that can be followed. Every Spec at Amazon is a 6-Pager Document – forcing people to establish clarity of thought and articulation.

–       Another good alternative is the 1 Pager “Lean Canvas” by Al Ries.

–       Equally important is to figure out Non-Goals – “What is not in Spec”? What are the features you need to remove! (Cue Reference: Joel Spolsky on Functional Specifications and an example Functional Spec.)

–       It’s also important to be clear on “What” requires a spec and What doesn’t. Both at Slideshare and MakeMyTrip, the team goes through multiple “Lights-on” stuff that they need to perform to keep the business running on routine basis. And these are fast-track enhancements and modifications driven by immediate business needs and marketing requirements. The Lights-on requirements are different from Core Functional Specs for the product roadmap.

–       Another criteria that decides how detailed the spec should be is based on the number of users getting impacted.

–       How do you handle customer requests with investment requirements that are not justifiable on the ROI? There are multiple considerations to this. The “Life-time Value” of the customer is important, and if such investments allow you to enhance it and calculate ROI in longer term benefits, it may still work well. There are alternative ways to look at this though. In the experience of Aneesh at Capillary, they had divergent requests that led to a very different direction for the Product and transformed it from “Mobile CRM” to “Intelligent CRM”. Another possibility could be to look at partner ecosystem and see if there’s a synergetic way to address these needs.

–       How do you manage your customer requirements into “Not to have” features? How do you single out the noise? While it is nice to think of an ideal situation of getting the product requirements at the planning stage, when the customers use the product, they often come back with plenty of views that need to be funneled down. When you have to discard some requirements, it is important to “talk to a lot of people” to ensure weight. Also, some of the requirements die-down on their own, clearly indicating noise factor. It is a balancing exercise between reducing the hassles in customer feedback process and creating enough friction to dampen the noisy “Vocal Minority” (the term that Amit R uses to refer to the few customers that may be so noisy that their voice seems more important than is worthwhile for the product).

All attendees at the Playbook roundtableConversations on #prodmgmt

Hiring and Product Management Structure

As per Amit R, Product Managers should be (are!) Second-in-command in the sense that they decide the future of the company. Considering this, it is critical that one single product dimension doesn’t overweigh the hiring process. So, intake process for Product Managers needs to follow the 70% rule – The Product Managers need to be aware on all the broader and holistic dimensions of running the product business including sales, marketing, operations, design, and so on, with 30% depth on the critical Product Management areas.

Some of the specific tips on this from Amit S and Amit R, and some from participants:

–       Determine if the candidate can think holistically and de-clutter the thought process in the crowded set of inputs. Ability to deal with ambiguity.

–       Product management is typically a “common-sensical” thing. Look for common sense and intuitive angle.

–       A great product manager would do well on what can be referred bluntly as “dhandha” (Money part of the busines). You cannot afford to have a Great product with “no” money.

–       One of the participant companies built their structure around Customer Success. Majority of the Product roadmap is driven by the Customer Operations, Tickets, and resolutions – and driven by how customers used and viewed the product in B2B scenario. In such cases, they typically found it useful to move folks from Customer Success team into the Product Management areas.

–       In case of another successful participant company, the CTO is playing the role of Product Manager and it is working very well for them.

On the relationship between the CEO/Founder and Product Managers. As per Amit S, Product Manager is the CEO of the Product, while the CEO is (of course) the CEO of the Business. One of the challenges for the Founders is how quickly they are able to let go he Product Management and start focusing on the business and Product metrics. Amit R also emphasized that it can work cleanly with the CEO focusing on the business aspects while Product Manager focused on the Product aspects while maintaining the alignment. 

Where should the Product Manager Report? At high level one case say that it depends on where you are in the evolution of the product/company, and what the Product really means to the vision of the company. However, over time, Product Management needs to be separated from Marketing and Engineering. In essence, Product Manager shouldn’t report to the Engineering or Sales or Marketing. In corollary, there should not be a reporting into Product Manager as well. Product Manager is a “Glue” job, and is key to a healthy tension for the product direction.

Product Manager is WHAT of the Product – Defines what (functionally) should be built. Engineering is HOW and WHEN of the Product – Details out & manages “How” (technically) and “When” (schedule-wise) should the stuff be built.

One needs to also establish clarity on Product Management being different from typical Project Management. Also, there are strategic aspects of product that are owned by the executive management, however, you always need a “Champion” of the product that is independent of the other forces that drive the organization.

Importance of Data Guy! Another structural aspect that Amit R emphasized on (multiple times!) was the importance of a “Data” person in the Product Team. This role is almost as important as a Product Manager in the sense that Data & Analytics can play a key role in the product Roadmap definition. There are various flavors of the Data – Dashboards and reporting, Product Management level Metrics, Decision Science, for instance. Interesting to note is the fact that at LinkedIn, next set of products are heavily influenced by “Decision Scientists”. (Cue References: Hal R Varian, Chief Economist at Google and DJ Patil)

All attendees at the Playbook roundtable All attendees at the Playbook roundtable

While there was a whole lot of structure to these discussions, we had some extremely valuable side discussions that link back to the Product Management, and very important to address. Here are some! 🙂 

Positioning. For a clear direction for Product Management, the positioning of the product in the market is a key factor. How do you refer to the product? The answer to this question, in case of start-ups, seemed unanimous that the start-ups are too limited in resources/focus/energy to be able to create a new category. Aligning to an existing category with a differentiator is the key to early success. For instance, Slideshare referred to itself as “Youtube of presentations”, Vatika positioned itself as Parachute with Additional ingredients, “Busy” positioned itself as Tally with better inventory management and statutory reporting.

(Positioning is an important theme and comes with lot of related broader areas for considerations for Product Companies. We will have a round-table specifically around Positioning in near term) 

What’s a Product? (A rudimentary question, I know! But worthwhile to hear the perspectives! J) How do you differentiate functional Product Management from the technical side of it? As per Amit R, “Product is the core experience or core touch-point for your end-consumers with your business.” It is worthwhile to note that the various types of customers may have different ways to access the product and there may be different ways to define the touch-points for every segment. For instance, Slideshare follows a Freemium model where 5% of the Paying customers may have a different set of touch-point experience from the rest of 95% free users. So various segments, such as Free B2C, Paying B2C, Paying B2B, and Partner B2B may all have different touch points with the same Product.

How do you get the Product Managers to champion the cause of usability and aesthetics? As per Amit R, in case of Slideshare, CEO happens to be from the usability background and that helped a great deal, since the thought process permeates across. It is important to engrain the usability in the way of the product management, since you cannot bolt it later, as per Amit S. There are various ways MakeMyTrip tries to do that. One of the eureka moments, for instance, for Engineers and developers was when they were shown a “live session” of a user through the Screen capture tool. It also helps to have the live user sessions in front of the product team. Some of these approaches can build that appreciation for the user actions in the minds of product team, over time with sustained effort.

Retention and Customer Lock-in: Slideshare has learned the harder way that ignoring Emails as a mechanism for customer engagement and retention is costly. LinkedIn relies on Email based “Customer retention” and “Returning Users”. Jeevansathi.com uses a strategy to map the customers in various life-stages and uses various Email and SMS templates to engage them even through the very short life-time of 3-4 months.

The Mobile Storm: As per Amit S, having a Mobile Strategy through this year and next year is critical for the product companies. Web is no more the only option, and for some products, it is becoming a mere secondary. Mobile First makes sense. The transactional figures for Mobile are increasing at such a rapid pace, that an afterthought based Mobile based functionality may not work so well.

If this is any indication of the things to come, the product ecosystem will benefit immensely from the initiative. Looking forward to the furutre editions, and share more!

Please share your views!

Notes on Product Management – insights from Slideshare / MMT / ex-Google PM

Avinash Raghava, who is doing a wonderful job of getting product start-ups together all over India, organized a product management roundtable with the help of Aneesh Reddy(CEO, Capillary). They invited Amit Ranjan (Cofounder, Slideshare – acquired by LinkedIn) and Amit Somani (Chief Product Officer, Makemytrip, ex-Google) to share their insights with a small set of entrepreneurs.

Credit for all the good stuff goes to Amit Ranjan, Amit Somani and Aneesh Reddy. Notes are rough. If anything is unclear, feel free to comment.

Here are some quick notes/thoughts from the event:

Who would make a good product manager?
Someone who can do 70% of everything (coding, design, listening to users etc.)

Best way to find a product manager in India is to find someone who did a startup but failed – he/she is likely to know all the various aspects that go into managing a product.

Someone who can lead by influence and manage to juggle all the balls in the air. Should be someone who can say NO.

It’s a very tough position to hire for – you need to have patience – you might go wrong the first few times. Once hired, give them around 5-6 months to get the hang of the whole thing.

What does a product manager do? What is his role about?
A good product manager would understand the requirements from various constituents and write a detailed specification, plan for bugs, testing, urgent requests and then create a product roadmap/deadlines.

A product manager has to identify and write down what metrics will move once the product is launched (e.g launching the mobile app will increase our repeat orders by 9%) – in some cases it is just to ensure that people work on things that matter but overtime it also brings more accountability.

User specs should have – what all do you need, who will use it and why – need to be elaborate it before you give it – need a hypothesis that will it move an X metric. Read thetwo page spec document that Joel Spolsky wrote for a fictional website What time is it? It should also have non-goals – what the product does NOT try to do.

Engineers tend to underestimate the time it’ll take – product manager needs to be able to correctly estimate how long something should take. And you will get better at it with time.

Use the 1/1/1 rule – sit with the engineering team and plan what needs to be accomplished in 1 week, 1 month and 1 six-month period.

People want to see the product roadmap – it is important for the CEO / Product Manager to communicate this to their team mates since a lot of people feel uncomfortable if they don’t have a clear idea of where the product is headed. (Amit Ranjan mentioned that people may even leave if they feel that the founding team does not have a clear vision – but the nature of start-ups is such that it is bound to happen that the product roadmap keeps evolving)

You need to hire coders who have a design sense (that eliminates 70% of work later).

Role of special data or analytics person has become very important (Amit Ranjan said that he could see that products of the future will be decided and influenced by data scientists). It is very important to get such a person on board early. Someone who has crunched SQL and nosql logs etc and can find trends and look up aberrations. Read up on Hal Varian and DJ Patil to understand more about this.

Difference between customer requirements and product requirements – customer requirement only becomes product requirement when more than 3 people require it (it’s a rule of thumb) – (People shared various tricks they use to ensure that the customer requirement is serious – “just wait for a few days and see if they come back with the same request”, “ask them to email it and not take feedback over the phone” etc. – these are situations where there is too much feedback coming your way. In most cases, it is best to make it as easy as possible for people to give you feedback).

Keep product engineering teams small – Amit Somani mentioned Jeff Bezos Two Pizza rule i.e. if the team cannot be fed by two pizzas alone, it is too big. Read more here.

Try to do daily scrum – gives everyone a sense of what everyone else is doing and ensures that people are making progress

Everything is a 6 page document – another Jeff Bezos funda for getting clarity. So a specification or a product request could be a 6 page long form document which ensures that the person achieves clarity before building anything.

You need to benchmark your product against other products especially in enterprise. When starting a product from scratch this can be a really useful exercise.

Amit Somani suggested a mental trick – before building a product, write a one page press release for the product that comes out upon product launch – what will this press release have? What the key features? The target audience etc. This PR drafting exercise could help you decide what to build, what is critical, and for which audience.

Don’t ignore email as a channel for activation and returning visitors

Product activation – Use banners on your own website – do get them to take action – on landing page – on other parts of the website

Track at your mobile traffic – people at the roundtable reported some crazy growth numbers for mobile internet usage – huge sites are now getting 20% to 60% of their traffic on mobile. Mobile traffic is split 50%-50% on mobile browser (including WAP) and mobile apps. This was a big eye opener for many people.

Tools people recommended

Use Trello (a Joel Spolsky product) to manage your product

Use Zapier business tool to connect various sources of product input (e.g. taking Zendesk tickets and automatically creating Github issues)

Use Clicktale or Inspectlet to record user sessions

Use Morae for recording users’ reactions when they are using your product ((Amit Somani mentioned how they put a live usage recording on a LCD screen in the technology room so that engineers could understand how their products were being used – it lead to a lot “can’t he just click on the button! Why is he scrolling up and down!”). One way to get users for such recordings is to ask interview candidates who come to your office to use your product and see their reactions.

Use a call-outs software when introducing new product features (like Cleartrip / WordPress / Facebook do).

Concluding notes
This was one of the most gyan-heavy sessions that I’ve attended. It was useful to hear things from people who had been there done that. Aneesh (even though he is based out of Bangalore) had taken the lead to do this with Avinash and our hope is that the group meets every 6 weeks to keep the conversation going. We’ll keep you posted.

Feel free to email me at ankur AT Akosha dot com if you’d like me to give more details to you.

On a related note, there was some basic debate about what a “product” is. We didn’t get into it at length because everyone in the room intuitively understood what a “product” was. However, we had internally debated about it – if you are interested, do read –Understanding Product v. Service [ThinkLabs Notes 1].

Reblogged from the Akosha Blog by Ankur Singla

Some Takeaways from the First iSPIRT Playbook Roundtable on Positioning & Messaging for Products

“99% Practice, 1% Theory”. This was the ground rule laid down for the session by the workshop facilitator Shankar Maruwada at the beginning. Sounds very much like the tagline of a popular softdrink brand that’s No Bakwaas! No wonder it came from someone who has loads of experience in the FMCG space, built and sold an analytics company and has more recently given life to what is arguably India’s biggest consumer brand, Aadhar.

Shankar sharing insights at the iSPIRT Playbook RoundTable

The theory lasted just a couple of minutes with Shankar telling a simple, yet a compelling story of how the Indian flag evokes a strong feeling even though it is nothing but a geometrical shape consisting of rectangles and a circle! The point that a compelling visual and a strong emotional connect can touch a strong chord was driven home very clearly. Over the course of the next 3 hours, Shankar orchestrated a highly engaging and interactive session with the participating companies, making them think hard and think deeper to help them think in the right direction. What also helped immensely was that Shankar had gone through the profiles of each of the participating companies and knew the challenges each of them were facing.

The participants were involved in exercises that helped them think beyond the regular product features and benefits. Emphasis was placed on understanding and communicating the whys of the product rather than the hows and on ways of building an emotional connect with the customers that will resonate strongly with them.

The participants were made to think through the different stages of the communication to customers.  For each step, two companies shared their thought process in detail with other participants sharing their inputs for the two companies. The participants found it very helpful to pick the brain of other entrepreneurs and learn from other entrepreneurs. A couple of participating companies probably found their one-line message or the keyword that signifies their product offering by the end of this workshop!

Shankar sharing insights at the iSPIRT Playbook RoundTable

Here are some of the key takeaways from the workshop, based on the stage and the audience to which one is communicating to:

Idea

  • What’s the grand idea that can resonate with everyone? This is beyond the product features, pricing and has a much higher connect. E.g. Education with the reach of television, your own personal secretary..
  • If possible, use connections, metaphors and analogies for better impact. E.g. YouTube of…., Google of…..

Setup

  • What will make your customers sit up and take notice? This is something related to their business that they wouldn’t have thought of or know about and you instigate that thought through your messaging. This should make them care for your product offerings and be interested in exploring more and have them say, let’s talk! E.g. Did you know that you can now teach a million students right from your classroom? Did you know that 30% of devices in your corporate network go undetected and potential sources of malware that can disrupt your network?

Benefits

  • What is it that the customers can actually put to use? What are the tangible benefits that the customers can derive out of your offering? E.g. Deliver courses over low bandwidth and hence reach out to a large number of students even in remote locations, create attractive charts and graphs to derive meaningful and actionable insights out of your data, carry out quick experiments for merchandizing on your e-commerce website with very little involvement from your engineering team

Features

  • These are the features and functionalities built into the product. These would explain how the product works. E.g. Various roles built in for access control and permissions, different interfaces and interactions for different user types, alerts, reports and notifications. 

As you’d observe, the how part becomes more prominent as you move from the Idea stage to the Features stage and the why part becomes more prominent as you move in the reverse direction. Depending on the whom you’re speaking to in the scheme of things at the customer’s end, you can focus on the appropriate stage and communicate accordingly.

iSPIRT Playbook RoundTable

It is said that well begun is half done. Considering that this was the first such roundtable, the response from the product startup community was very encouraging and the participating startups found it to be very relevant and effective. The engagement with the participants will continue even beyond the workshop. The startups will be in regular touch with each other, share their inputs and the learnings derived from the workshop and update on the progress.

Here are some books that Shankar recommended:

There are more such Playbook Roundtables planned in the coming days across various locations and hope the product startup community will make the best use of those and benefit from them.

Announcing the First Playbook Roundtable: Positioning and messaging for Product Entrepreneurs

We are pleased to announce the first Playbook RoundTable for Product Entrepreneurs around Messaging & Positioning. A strong, differentiated & memorable product messaging is essential in creating traction for your product. Effective product messaging speaks directly in the langauage of your target audience. This Playbook Roundtable is brought to you by iSPIRT. One of the initiatives of iSPIRT is to convert conversations into playbooks for product entrepreneurs.

This Playbook Roundtable is led by Shankar Maruwada and is intended for companies that have a software product (consumer or enterprise), have initial customers and are trying to scale to the next level. They are keen to make more crisp their value proposition to the target audience and more clearly articulate their position relative to competitors.

This Playbook RoundTable will be interactive and will help your team step into the role of your target audience, map your features to benefits, organize those benefits into message themes, and summarize the product in a positioning statement.

To apply for this workshop please send a PDF document(one pager) to avinash(at)ispirt.in with the following information by 23rd March ‘2013:

  • Name of the company
  • Name and title of the intended attendee
  • Mobile phone of attendee
  • Email ID of attendee
  • The top two practical problems your company faces in messaging, communicating, positioning your product, that you would like help with. 
  • Top 2 desired outcomes from the workshopPlease share, as briefly as possible, your current resources and efforts in this area
  • Write (max 150 words) on the ‘What’ and the ‘Why’ of your product, in simple language. You may accompany this with a single visual (optional).
Find more details about the playbook roundtable here.

An iSPIRT’ed Budget

One of the pillars of iSPIRT’s mission statement is a focus on converting the needs of the product ecosystem to policy direction.

One of the first undertakings of the iSPIRT community will be to formulate suggestions on how to improve Finance and Investment related policies to yield better results for this industry. And what better time to do this than in the run-up to the Budget presentation on 28 th February?

We plan to host and facilitate open and transparent online discussion around the key topics where current policies should be revisited. The discussions will be seeded with the release of a series of Blue Papers –short discussion documents identifying the key pain points, what is at stake, and how we should proceed as country.

Over the coming four days, we will release a new Blue Paper each day on the following topics:

We encourage everyone to help us collaboratively build on these initial viewpoint documents. We will close the discussions as we approach Budget Day, and after the release of the Budget will then create a set of assimilated viewpoints stemming from the Blue Papers, the discussions that have transpired online, and reflecting on the actual Budget.

These viewpoints will then be shared back with the Government as inputs reflecting the views of hundreds, or hopefully thousands, of product entrepreneurs and ecosystem participants.

Keep checking back here over the coming days, and we hope to hear your voice, too!

Will B.PAC and iSPIRT Transform Urban Politics & the Software Product Industry Respectively?

While we usually focus on product, process and business model innovation as the main facets of innovation, some of the most impactful innovation can be the result of new organizational forms.

Take the case of India’s white revolution. This was driven by a unique 3-tier structure of organizations – the farmers’ cooperative at the village level as the basic organizational unit; a district-level federation of cooperatives with milk processing and marketing capabilities; and a state level apex body with brand and product management capabilities. And, behind this structure were larger organizations like the National Dairy Development Board at the national level that channelizes resources, support long-term investment activities, and accesses new knowledge and inputs. This arrangement takes advantage of flexibility – when required NDDB can look like an extension of the government, when required it is an independent body working with farmers’ cooperatives. This flexibility has helped it manage in a complex environment.

Last week saw the birth of some organizations nowhere as complex as the milk production structure, but with the potential to have major impact.

B.PAC

NR Narayana Murthy launched the Bangalore Political Action Committee or B.PAC as it is being called. This is the first time we are seeing an organization christened as a PAC in India, though this is a common term in the US. I presume this similarity is not just a matter of coincidence. PACs in the US are not political parties, but organizations created to advocate and support a particular agenda. The B.PAC has similar objectives. At one level it aims to restore the quality of life of the city of Bangalore. But at another level it is a pressure group for more political power to cities which are the value creation engines of a modern economy.

The B.PAC’s initial agenda is to enhance urban (read middle class, educated) voter enrolment and voter participation. They also promise to support candidates who back their agenda (new forms of city government, more resources, better urban planning, etc.) In the forthcoming assembly, parliament and municipal corporation elections. Subject, of course, to their meeting other criteria like no criminal cases against them, no record of corruption, etc.

B.PAC has been formed by a group of resourceful and successful individuals who have for long been expressing their dissatisfaction with the state of affairs like Kiran Mazumdar Shaw and Mohandas Pai. It represents their response to many of the issues they have raised in the past falling on deaf ears, and their inability to have a sustained impact on the political system.

Of course, the “involvement” of successful industrialists in efforts to improve Bangalore is not new. During the chief ministership of SM Krishna (1999-2004), the Bangalore Agenda Task Force was created under the chairmanship of Nandan Nilekani. The BATF tried to play the role of a coordinating body, creating a platform for different civic agencies, citizen groups and the state government to come together. While the BATF did manage to do some of this as well as have new bus shelters and toilets built, it was a body without any political legitimacy and was hastily disbanded after the Congress lost the 2004 elections in the state.

Newspaper reports indicate the existence of a similar attempt in the last few years under the chairmanship of Rajeev Chandrashekar. However, this one has been low key, restricting its role to that of a think tank. But again the long term impact doesn’t appear to be substantial.

B.PAC is an interesting development because it shows an inching of rich, successful “middle class” entrepreneurs towards electoral politics. Though apolitical in the sense that it is not a political party, B.PAC clearly has a political agenda. It represents a growing realization that technocratic approaches can’t solve India’s problems. It also suggests that the efforts to create alternate public spaces such as those tried out by Janagraha or the BATF itself could have only limited success. The creation of the B.PAC is a welcome development, for the next logical step will be immersion in electoral politics. I hope to see a party such as the German Green Party emerging out of this process with the ability to push urban issues at the national level.

iSPIRT

The second organizational innovation in the last week was the creation of iSPIRT – the Indian Software Product Industry Round Table. It came into the public view amidst controversy with a Times of India headline announcing it as a breakaway trade body from Nasscom. iSPIRT’s spokesmen were quick to assert that the organisation is an industry round table (not a trade body), that it will not offer membership, and that the founders will continue to be part of Nassom (Disclosure: I am a part of the iSPIRT Founding Circle).

I am excited by the prospect of iSPIRT because of the new activities it is promoting. An important role it will play is to act as a market maker. India has lakhs of small and medium businesses. These businesses are important sources of employment and economic growth but they face a major challenge of maintaining their competitiveness. Information technology has the potential to enhance the efficiency of these businesses. However, these SMBs often lack the ability to evaluate vendor proposals. They are price-sensitive, and risk-averse as far as IT is concerned. Burnt by past experiences, they are wary of making fresh investments in IT.

Under its iSMB initiative, iSPIRT plans to bridge the gap between domestic software product vendors who have relevant solutions and SMB customers. ISMB will study different verticals, map needs, and certify products meeting the vertical’s needs. Only product companies that have customer dispute resolution mechanisms in place will be accredited. Product companies will get feedback on where their solutions fall short of customer requirements. This initiative is designed to bridge the trust deficit that exists today between vendors and users.

ISMB will build on the positive experience of CIO Connect, an earlier effort to bring Indian product companies and large Indian corporate IT users together.

Both B.PAC and iSPIRT are Market-Makers

Though in theory markets provide the opportunity for sellers and buyers to come together, information asymmetry and high transaction costs can prevent markets from functioning efficiently. Initiatives like ISMB and CIO Connect help smoothen out these market imperfections.

B.PAC can also be seen as a market maker. A democratic system in which a whole chunk of voters does not participate will not reflect the needs of different interest groups accurately.

We tend to expect government to combat market failure. Both B.PAC and the ISMB initiative of iSPIRT represent voluntary, community efforts to do so. I will watch both these organizational initiatives with interest.