6th iSPIRT Playbook RoundTable: Challenges in building a global software product company from India

In the continuing series of Round Tables product veterans Samir Palnitkar, ShopSocially and Jatin Parekh, AirTight Networks took the participants through a journey of discovery about why they want to go global and taking a critical look at the challenges they must overcome.

It takes a guy like Samir to lay the foundation for such a Round Table, having stoked the discussion with his experience and adding fuel by way of eliciting ideas and experiences of others. There’s no quick formula but the session did throw up some easy mantras to achieve those Global ambitions…

Some interesting takeaways from this session :

TEAM:

–       Hiring for overseas is always a challenge and you can’t be careful enough

–       Get a co-founder with a sufficiently high stake in the game, and one who is ready to adapt to the call of the hour.

–       If you know the person from earlier, nothing like it

–       Stay away from expensive consultants and retainers. Find someone who will take less cash (and therefore has had a prior successful exit / financially secure)

–       Write down the issues, objectives, compensation, way things are done, who does what, 5 year vision, etc. These discussions need to happen 

Experiences of those present:

–       One of the RT participant founders even camped in the US for 3 months to find the right guy, interviewing over 15 persons identified through various contacts. They evaluated trust, skill and cultural fit before deciding.

–       Most people do not want to be the lone member of startup in the US because all decision making would happen in India. One of them had a member already selling remotely so were thinking of moving that person to US.

–       If there are 3-4 co founders, there is enough mental bandwidth to get one person to US for 6 months to set things up.

–       Get partners to sell for you, they front end and sift thru the leads. May be encourage one of the partners to join you, as did one entrepreneur who had a good partner in E&Y front ending and finally robbed E&Y to get his co-founder !

–       In a nutshell, don’t compromise on this first hire. 

PREPARED TO TAKE THE FLIGHT ?

–       Start selling globally only if you can fund the sales cost for at least a year

–       It’s ok to do some services revenue to generate some cash. But this is also the biggest pitfall, if you end up doing too much customization that cripples you later. 

Key considerations:

–       You have to learn how to sell if you don’t already. Thumb rule is – if you can’t sell your product, nobody can.

–       You should have a sufficient funnel and regular flow of enquiry / conversion / sales and cash flows. Ok that’s a lot to ask but then that’s what it needs !

–       Prepare the Sales play book. A new person cannot invent the playbook to sell in US for you. 

PRODUCT MANAGEMENT

–       Do you want to keep Product Management close to the customer or close to the R&D team?

–       Typical challenges in this are the ability to be aligned. Clear internal communication is crucial in motivating the team for the higher purpose

–       Delivery teams are usually in India, however you need to deal with the challenges of motivating team from a distance and account for cultural differences

The practical Product Manager:

–       Understanding the higher purpose and communicating it again and again is very important. If engineers are in the same office as sales guys then its easy, motivation happens. But if teams are physically separated then you have to build the channel to keep that communication going.

–       Communicate back to sales what problems engineering is facing.

–       Product Manager must have a regular travel plan and must meet customers if working at a distance from the market. This is crucial to get the alignment early on.

–       The PM cannot be note taker, taking customer requirements and giving it back verbatim to engineering to build. He must understand, negotiate and make intelligent distinction between features and requirements.

–       Priorities should be clearly published in writing.

–       Engineers should have the freedom to think and push back on features, but within boundaries. That’s when they can understand the purpose vs just coding.

–       Engineers must have first hand communication with customers, go for customer meetings, handle support calls etc.

–       When hiring engineers, set the expectation upfront that you have to do everything, and even learn outside your core competence. A Startup cannot afford to have people rigid within their own area. 

MARKETING

–       The biggest conundrum is in expectation mismatch, US teams being very “look” orinted and India teams being “fact” oriented

–       Interpretation of specs is usually different for each team, and quality of collateral needs to be extremely high to appeal to a US audience

–       The simple approach is to keep everything that requires a “handshake”, in the US and to teach India teams to be perfectionists.

–       If you need to get copywriting, don’t even think of getting it done in India. The lingo, the flow has to be completely American – leave that to an American.

–       Use a professional UX design shop if you need to

–       Use professional agencies for PR, like PRWEB, etc. 

SALES

–       Necessarily should be close to the customer. If the product requires a handshake, then you definitely need a US team member.

–       At the very least you need someone to stay up at night and receive calls

–       Prospecting via Linkedin, using polls and doing cold calling from India are usually successful approaches 

Sales and Marketing in the US is a big discussion in itself. A lot was left to be discussed, perhaps deserving an entire session devoted to selling in the US market. Another day, another Round Table then. 

ProductNation is the Go-To destination for many a successful software product. There are several amongst us who have tasted success in the global market. Do share your experience right here.

Fifth iSPIRT Playbook Roundtable: Product Manager, the Skill in Demand

It is a cliché to say product management is both art and science. The product manager’s function encompasses a range of tasks, only limited by the company’s vision. Deep Nishar, Senior VP, Products and User Experience, at LinkedIn, told the audience at Nasscom Product Conclave 2012 that, “product managers should have brain of an engineer, heart of a designer and speech of a diplomat.” The product manager with such an expanse of skill set is hard to find in India. With the intention of bringing experiential learning and to ignite conversations among product entrepreneurs so that they learn from each other, iSPIRT, the think-tank for startups, is organizing Playbook Roundtables that facilitate transferring of key knowledge through an open discussion. In the fifth Playbook Roundtable organized at Chennai by iSPIRT, Sridhar Ranganathan, who has rich experience as a product manager, shared anecdotes quoting from positions he held at Zoho, Yahoo, and InMobi to define who a product manager is.

Sridhar’s naval architecture career did not last long. A chance meeting with Sekar Vembu, founder of Vembu Technologies, landed him a job at AdventNet (all three Vembu brothers, Sridhar, Sekar, and Kumar were part of AdventNet then). He was placed to manage a team that was working on a product. Not a geek, he took three months to understand Java Script. A management shake-up at AdventNet properly designated him as product manager. Then began his tryst with product management. At Zoho, the discipline of product conception, execution, and delivery was practiced with a high level of checks and balances. With a small team and margin for error almost non-existent, Sridhar learned to work with constraints to deliver software products. Moving on, he headed the team working on Maps at Yahoo. This proved to be challenging as managerial oversight was nonexistent but any senior level meetings thrashed any feeling of achievement. Sridhar by now had crafted the art of product management and he had an excellent team to work with. Then at InMobi, his challenge was scale. He was able to successfully navigate through the phase where InMobi’s ad impressions went up from 50 million per month to 2 billion per month.

The product culture

There were 15 participants from OrangeScape (Suresh Sambandam and team), Fresh Desk (Smrithi, product manager), Kallos (George Vettah), LPCube (Lakshman Pillai), Array Shield (Vasanthan Kumar), ContractIQ (Ashwin), Twenty19.com (Karthikeyan Vijayakumar), RailsFactory (Mahendran), Fix Nix (Shanmugavel and team), Social Beat (Suneil Chawla), and Humble Paper (Vivek Durai), represented by its mostly founders. Suresh was keen to know how with a small product team (Zoho instituted a culture of a seven-member team to work on a product), Zoho was able to recruit college drop-outs and train them to work on products. Sridhar said if the company is big enough and has a strong culture (such as escalation of wrong codes, build times, and customer complaints to the highest level if not done within a set time frame), such experiments are possible. In Google, you know the person who is going to work because of the recruitment process but at Zoho, you have to groom the person.

Sridhar strongly emphasized that data plays a big role in product management and went on to say that “if you build technology products, your core data model and technology stack determines your business model.” He listed various challenges faced by organizations such as SalesForce to remove duplication of data. For example, to change a primary key, Zoho needed 14 months. George Vettah added that Ramco had to reengineer its offering after SAP effectively took away its market share. Sridhar gave away one more of his product philosophies: “If there is a constraint in the product, and if you have the market, you could only pray that the market does not go away till you reengineer the product.”

Education to Product: the product continuum

Through a graph, he illustrated the various stages of the product continuum: Taking problem complexity on one axis and scale or impact on the other, he said, for low problem complexity and low scale, education (of the customer to tell them why your product) is needed. At the next level, process needs to be defined (to quote an example, the process of how to apply for a passport online), Still further, at the higher complexity and more users, you need to define the procedure (how to fill in the form of the passport application), and still at a higher level, you need to provide a solution to the problem. But for a very complex problem with the highest impact (nonlinear), you need a product. So by understanding the need and the impact, you can execute your product strategy.

The product manager

He said that the fundamental role of the product manager is to identify the product that has the maximum probability of success. “The success metrics of a product determines the product manager’s action,” he added. This was followed by an interesting discussion on how the founder passes the baton to the next product manager as the company scales up. Kaushik from OrangeScape provided a fine example. The product manager has to work on three aspects: hygiene, spoiler, differentiator. A hygiene part of the product is not impactful but without it the product wouldn’t work. The spoiler is beating the features of the competition, and differentiator is the difference that your product makes. Further, at the first level, the product manager has to find users for the product, at the next the user level should be scaled, say from 2000 users to a million users, and further at the next level, if there is a drop in user level due to competition, the project manger has to devise ways to retain the user level. These three different stages require product mangers of different skill sets.

Finding the right product manager

Finding the right product manager is a challenge. Sridhar said the right product manager is identified by his ability to align with the vision of your organization and should have the potential to grow with the organization. For him, the hiring decisions are not done in a day. Sometimes it stretches to two months as he engages in long conversations with the potential candidate. Then an interesting discussion on organization structure where most of the times the product manger is asked to “influence without authority” was discussed. “The product manager has to be temperamentally strong,” stressed Sridhar. In many organizations, the developers and engineers are not direct reports of the product manager. Engineering team is headed by a senior engineering head. But your input on the engineer decides his grading. So at most positions, product managers have to work with teams that don’t directly report to them. By telling the team the importance of the product and by selling the vision (by exercising influence without authority), you need to get the work done. Smrithi, from FreshDesk, said influence without authority was one of the attributes looked for in a product manager in her earlier employment. George Vettah added that research has shown that for product managers did not possess strong right brain thinking (creative) or left brain thinking (analytical), but somewhere that balanced both.

Building the product, managing the team

The ideal way to enforce build discipline is to have a release ready after every build. This is practically impossible but if achieved, gives the product management team an edge on product release. This also makes sure that the product isn’t broken. Several R&D prototyping needs to be done before the product is handed over for completion to the engineering team. Once the product is fixed and passed to engineering team, it’s difficult to tweak again. So spend as much time in R&D rather than “release early, release often.” Sridhar said managing multiple products only requires you to have user interface and data operability aligned.

The product manager has to find the right time to pivot. Sridhar asked the participants to read Lean Startups by Eric Ries. The author has dwelt at length on pivoting. Failures are part of product management but how the product manager negotiates such down moments counts. The product manager has to be mentally strong. For any of the product manager initiatives, winning the trust of the stakeholders is key, stressed Sridhar. He added that the satisfaction of seeing the product completed after your visual thinking on it is immense. He said that the product manager’s role is cerebral as it involves a lot of thinking.

There were intense discussions when each of the issues was discussed among the participants. Vivek Durai, who is now solely developing a product, said his priority listing has changed and his to-do list has a lot of elements to add up to. Kaushik said his respect for his previous product managers had risen after this discussion. Suresh felt some more improvements can be made to the discussion format. Suneil felt that the discussions were insightful and opened his world to product management. Karthikeyan Vijayakumar said he would implement a lot of stuff from the discussions.

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!

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.