Posted on

I am the Product Manager

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

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

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

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

Strap the Product Manager Hat tight.

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

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

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

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

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

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

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

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

4. Do SEO, plan the adwords campaign yourself.

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

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

“I am the Product Manager”

Guest Post by Venkat Kandaswamy, CoFounder, ApartmentAdda

Posted on

The Product Manager’s RuleBook

The Product Manager’s RuleBook

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

1-wYnDe5eOdU0UxPD0-KecOA

So you are the Product Manager, Right ?

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

You are the mini ‘CEO’

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

Rules

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

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

Author – Vivek Khandelwal

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

 

Posted on

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

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

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

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

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

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

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

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

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

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

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

Posted on

Using the product roadmap to keep an organization in sync

When organizations are relatively small, it is possible to keep all parts of the company – execs, PM, sales, engineering, QA, operations, etc – in sync with the direction and with the vision of the company. Communication across the company can be seamless and everyone can remain aligned to what they are working on and understand how their work maps to the broader vision.

However, as companies scale up, it is very easy for this chain to be broken and for a hitherto finely tuned company to get out of sync. Examples of this happening:

  • Deal-driven features: Sales promises a feature to a customer to close a deal and it gets added to a plan. After a few months, everyone forgets about it and it gets dropped. Eventually it blows up as an escalation when the customer is now upset that promises were not kept.
  • Vision changes: The exec team makes changes to the vision as the markets changes. This requires a replan with new features coming in and some features in plan being dropped based on shifting needs. This does not get communicated down the chain and development remains marching to an older beat.
  • “All Features Accepted”: Every few days a new feature request comes in and gets added to the plan. Nobody says “No” early enough, a commit gets communicated externally and in the end the product becomes a mish mash of features, with no clear vision and becomes impossible to use. Without a consistent plan that resonates to the vision, the product manager risks putting out a product that makes noone happy. The PM is the gatekeeper to avoid this from happening.

These are all examples of breakdowns in communication. It is the product manager’s responsibility that this does not happen. A product manager can use their product roadmap as a central part of a simple process to make sure that all parts of the company remain in sync. Changes will happen – that is a part of startup life – but the important thing is to make sure that the changes as they happen are clearly rationalized, communicated across all teams and all teams are kept in sync with where things are.

The best product roadmaps define the themes of the market that are relevant, the long term vision of the product (about 2-3 years out)  as well as the shorter-term term features (quarterly breakdown over the next one year). While this is maintained by the product manager, this should be communicated regularly to the sales, dev and engineering teams. The product roadmap should be shareable externally to prospects, customers and other external stakeholders. Done right, the product roadmap becomes the central part of the process of keeping the various teams in sync.

Product Alignment Process

The process involves creating:

A vision document : Simple 1-2 pager describing where the company will be in the next 12-24 months. This is done in concert with the execs and aligns with the company’s overall strategy. This is shared with everyone in the company and externally as well. Normally this is part of the lead-in to a detailed roadmap but sometimes this can live separately (especially in multi-product companies where the vision is broader and maintained by execs). This is versioned and is available to everyone.  I prefer the use of Google slides with read-only link shared across the organization.  A well defined and strong vision ensures that any feature request that does not align with the long term vision can be dropped early. The product manager meets regularly with the execs and keeps this in sync.

An external “one-slide” roadmap : This is the product roadmap as it is traditionally defined. The deliverable here is a simple one-slide roadmap showing the quarterly deliverables of the marketable features for the next year. This can be shared externally. As above, Google slides with a shareable read-only link works great here. It is versioned to be consistent with the vision document.

XYZ Car service Road mapFigure 1 : Example external roadmap for a fictional car ride share company. One Google Slide with the next 4 quarters of marketable features.

An internal / detailed roadmap: This builds on (2) and adds internal deliverables – like performance improvements, UX changes, engineering focused tasks, etc. This is the detailed, internal-facing roadmap. This version allows the team to make sure that the engineering focused improvements are not lost in the shuffle. This allows the team to make progress on reducing technical debt while continuing to execute to the market.

XYZ Internal Roadmap
Figure 2 : Internal roadmap shareable with dev and QA managers. One google slide that builds on external roadmap.

The details from the internal roadmap are then mapped to a tool that allows for backlog tracking and planning. I prefer Trello for a Kanban-like tracking system but there are various other tools that work very well. 

Trello schedule

Figure 3: Using Trello to schedule the work outlined in the internal roadmap as a set of cards

Sprint planning: With the details from (3), PM works with dev management to build out the detailed plans for each sprint and map it to a tool to track this (I prefer Atlassian Jira) for this. At this level, this is really a detailed work plan that’s aimed at PM, dev and engineering teams

 

Xira screenshotFigure 4: Using JIRA for sprint planning. See blog for more.

And thats it.

What we have done above is create a predictable system where all product planning deliverables are kept in sync with one another. There are three critical attributes to making this process work:

  1. Versioning: All the documents above should be synchronized. The latest versions of each should all relate to one another. Where a change is made, the older version should be versioned and there should be a clear indication for the reason for change. It should be possible for any stakeholder to review past documents to understand the reasons and the velocity of changes.
  2. Relevant Access: To avoid irrelevant information being communicated to the wrong audience, appropriate access should be given to the right stakeholders for the vision (everyone), external roadmap (sales, execs, PM), internal roadmap (PM, execs, support leads, dev leads, QA leads) and detailed sprint plans (all dev and QA)
  3. Single Owner: One owner should be responsible to make sure that they are in sync. The PM should own 1-3 above and work with engineering management to align it with (4)

Summary

Plans can and do change. The product alignment process defined above allows for the different planning documents across the product organization to remain in sync at all times so that as these changes happen, they can be rapidly and consistently communicated. This allows every employee to be confident that the work they are focused on is in sync with the vision of the company. And that will help the company move quicker and more efficiently as a result.

Posted on

Product Camp brings hot product topics to the fore

Product camp is a unique event format where attendees get to drive the agenda. It is borne out of the bar-camp or un-conference movement that started in US and spread to other countries across the world a decade back. Traditional conferences do not allow attendees to provide inputs to the agenda. P-Camp gives them a direct opportunity to create the agenda, choose the topics and the speakers.  Product camps have spread in popularity across the world.

The next P-Camp, hosted by eBay/PayPal and supported by ecosystem partners iSPIRT, NASSCOM and OCC is on Sunday September 7th 2014, starting 9:30 am. Anyone can register for FREE.

This is the third product camp happening in Bangalore, organized by IPMA, and only the fourth in India. Here is a peek into the agenda that is still shaping up on indiapma.uservoice.com with top 4 voted topics.

Product Camp

These are the issues that the community is grappling with and would like to learn more from others who are doing it really well.

This Product Camp is seeing a total of 23 topics proposed by the community. 23 is a healthy number and the highest we have seen so far.  However, due to limited time only the top 9 will be chosen. The P-Camp organizers including the team at eBay/PayPal have pulled out all stops to ensure a smooth and fun day that includes lunch and beverages for hundreds of eager campers, surprise goodies and office spaces for break out sessions.

Attendees also get to meet and hear from Ravi Gururaj (NPC Chair) Ram Narayanan (GM eBay/PayPal) and Piyush Shah (VP of Products, inMobi) as well.

So, this Sunday, forget the malls and TV and the couch. Instead, camp out with your product guys and gals at the eBay office in Bangalore.

 

Posted on

A perspective from the other side – Seema Joshi, Lead Product Manager – BMC Software, #PNHangout.

In this #PNHangout, Seema Joshi, Lead Product Manager – BMC Software, shared with us her insights about Product management and the challenges and scope on the road ahead for Women Product Managers.

Why did you choose to be a Product Manager?

There are two aspects to why I chose to be a Product Manager. The first is related to the evolution of the Indian IT industry and the second my personal journey.

The Indian IT industry, after its beginnings in the 1980s, saw good growth in the 90s with the economy opening up primarily due to high cost arbitrage. During this time the industry was dominated by the services sector. In the 2000s, the industry was maturing rapidly due to economic downturn pressures and consequently margins were eroding and cost arbitrage decreasing. The services industry still dominated the IT sector as the cost arbitrage play was becoming increasingly competitive. We also began to see larger R&D centers, mostly captive, setting-up base in India. Now, in this current decade, the focus is shifting to total product ownership. With increased expertise as well as domestic markets, startups and VC eco-system expanding, product management is becoming a critical part of success. It is more critical than it has ever been. While we do have a growing leadership presence across companies in India from a R&D product and project delivery stand-point, product management and product leadership focus needs to be stronger to deliver great products to local and global markets through entrepreneurship or intrapreneurship. Product management clearly has a large role to play in shaping the course of the Indian IT Industry.

I am a Bachelor of Civil Engineering and I began my career as a structural engineer after graduation. While I loved my work building peoples’ dream houses, factories, bridges, etc. I knew that I was more productive and happier working with people. So, I took up an opportunity with eGain Communications- a product company in Pune in a customer facing role where, after sometime in this role, I moved to the sales team as I thoroughly enjoyed working with in a customer oriented role. We were a small team targeting new territories which meant wearing various hats from lead-gen, pre-sales, solution consulting, account management all the way to acquiring business. It wasn’t always easy, but it was challenging and educating work. After a few years in this role, I was offered a position in the product management team and the decision to move wasn’t difficult. I think I always was and still am a sales person at heart. So the proximity of working with customers to find solutions for their problems was important to me. At the same time, I had seen typical enterprise sales cycles span anywhere from 6-12 months. I now had an opportunity to bring to the table my experience of working with customers, their needs and expectations from solutions, etc. and, with the outside-in perspective to help build the product, I could indirectly contribute to getting business from a greater number of customers beyond my sales territories! The product management role was like a win-win.

It was both the opportunity and the challenge to be a Product Manager that got me into the role nearly a decade ago and it still continues to be my passion!

Great, you’re a Product Manager. So what do you really do?

I’m often asked this question and I have begun enjoying answering it, so much so that I have two versions of answers. For the people interested in a short answer I tell them – “As a PM I do lots of conversations using a ton of post-its, a set of lenses and glue.”

For the ones still with me, I tell them: a PM is responsible for the success of the product to maximize business value through the product’s lifecycle depending on the business goals—be it driving market share, revenues, customer retention or whatever the focus for that product might be in its life-cycle at that point. This requires a PM to have good understanding of the unsolved problems in the market to identify market opportunity. To do this effectively they need to bring out the post-its and engage with customers to understand problems in their context and what their pain points are.

They then need to use their short-term and long-term lenses to review this vis-à-vis corporate strategy, internal strengths, risks, funding, competitive landscape, etc. to come up with a business strategy to address the market opportunity and product strategy to build a kickass product.

With the strategy in place, they need to communicate with the entire value chain to help deliver this—right from exec approvals, working with engineering to build the product and with marketing to convey the planned product value, sales tools and processes to ensure sales is able to effectively sell to the right buyer and with support to ensure customers understand how to use the product in the desired way, etc. They need to be the glue between cross-functional stake-holders to ensure right execution.

Though a PM might not be responsible for each of these areas, it is very important for every Product Manager to still have what I call the imbibed-CEO attitude. You may not call the final shots in each case, but if you do not align and orchestrate various aspects while driving your areas of responsibilities, you might reduce the odds of your product’s success. A Product Manager really must be passionate and enthusiastic about everything related to the product to make it truly successful!

Managing a product demands multiple sources of information and skill. How can a Product Manager prepare herself for this role?

A Product Manager needs lots of post-its, glue and conversations as they do their daily jobs. Conversations are typically of two kinds—one in the listening mode to gather insights and the other communicating what to do and not to do and conveying value and ways to get there. The PM does not need to be the encyclopedia, but needs to know different ways to get this information that can go into the encyclopedia. It is really a mix of art and science!

There are recommended practices for the entire productizing process that can be used to source and communicate information effectively. Individually a PM can focus on some of the following to do this well:

  • Be a good listener: It is never about what the product can do. It is always about what the product can do for the customer. Engaging with customers and the market to understand problems in their context is critical. This involves being able to ask the right questions, understanding customers and their business and what their key pain points are as means is to identify pervasive problems.
  • Good domain understanding: It isn’t a pre-requisite for a PM to be a domain expert right from the beginning. However, to engage effectively with customers requires being able to do it in the context of their domain. So a PM needs to quickly get a good handle on how things work. Regular interaction with customers and prospects is definitely a great way to do this as well as following analysts and thought-leaders in the industry, tracking competition, attending industry events, etc.
  • Build an analytical approach to problem solving with a business-centric mindset: It is not about picking the first or the easiest solution or solving the problem of the noisiest customer. To derive the next set of outcomes, having understood the unsolved problems in proper context, requires being able to quickly analyze scenarios, potential opportunities, dependencies, financial implications, impact and mitigation plans. PMs need not be experts in each aspect but he needs to be able to evaluate options and work with the value-chain towards achieving business goals for which time and cost is critical!
  • Communicate effectively: Effective communication is the hallmark of a good PM. A PM is required to constantly communicate with various stakeholders to achieve a common objective i.e. to build a product that delivers value. For instance, a PM needs to communicate
    • Business opportunity and solution recommendations to execs for strategy and funding approvals
    • Product requirements to engineering to build the right product
    • With marketing to articulate solutions and convey the right value messaging
    • With analysts or customers to convey the solution and its value

If you fail to sufficiently communicate any of these, it could affect success!

  • Leadership and self-leadership: It is important for a PM to bring in the right vision, energize teams, influence, and be good at decision making for many a time it is about right prioritization and timely decisions. This cannot be done without passion for your product and its success. While good processes help reduce risk, even at an individual level, a PM needs to take charge and align and inspire teams towards their goals.
  • Belief, patience and perseverance: There are no two ways about it. In product management you’re in for the long haul. It is about a product’s journey towards success. If you want things to happen overnight, or view it just as a set of tasks from one release to another, you might end up taking the wrong paths. Keep the focus!

Women Product Managers – there are a few of them. Is it a disadvantage to be a woman?

Overall the gender diversity ratio in the Indian IT industry is approximately 25 % women, which is better than others. However, most women are still in traditional roles like HR and Marketing and to some extent engineering, technical-writing and delivery-centric leadership roles. The presence in product management and product leadership is still really small. In fact, in my 8 years of being a PM, both at my current and previous company, I have been the only woman PM in India. Of course it is a little different when it comes to global teams.

In India I have been on many forums and meetings where I am the only woman. Being a woman PM tends to have a two-fold challenge. For companies, organizationally, product management as a function is still not mainstream; it is getting better but it still isn’t there. This is further compounded by the lower women ratios overall and within the function.

One of the common challenges most Product Managers need to overcome is related to change—recommend change in strategy, change in practices to address opportunities, culture of organization, etc. If you’re the only woman in the room driving this, be ready with all kinds of data-driven reasons, proof-points and if-else conversations to make the change management smooth and effective to avoid “but, this is not how we’ve done it in the past” objections.

Beyond that, at a larger level, the challenge is a common one irrespective of roles—to have better diversity across hierarchies in an organization. If companies want to make a notable difference in diversity, it is crucial for them to cultivate a culture where women not only end-up taking more traditional roles like HR, Marketing, etc. but also actively encourage women to take up roles along technology leadership (as architects) or product leadership (product management and innovation) as we take the Indian IT industry to the next level AND if we don’t want women to be left behind once more time to only catch-up later!

I would also like to give a shout out to women in the industry to gear up for this and be prepared to play your part. Remember that what got you here won’t get you there and these days “lean is in”, so sharpen your skills to make a difference. For a better outcome tomorrow, it is a choice we have to make today—as individuals and corporates!

Is there a bright side for Women as Product Managers?

One of the key things for a Product Manager is to empathize with users and to care for the overall experience. Women tend to be naturally more attuned to this. They also come across as effective communicators and influencers. A PM needs to do a lot of communication as there are various stakeholders to be managed across ranks and a Product Manager has to be able to influence by bringing out the reason and value of why things need to be done the way they need to.

Being great at multitasking is a benefit as well. Recent studies are converging with the hypothesis that women are found to be better at multitasking than men. A Product Manager is always juggling between different things and different people and yet needs to keep all tracks aligned. It helps to be able to prioritize tasks, organize time and most importantly keep calm under pressure as they rapidly switch between activities.

Lastly, their leadership styles help too. PMs not only need to nurture a product from conception through its life-cycle but also drive larger teams towards a common objective without having any authority over them! This is corroborated by the increasing number of women taking up significant roles in corporations. Women Product Managers are definitely making a mark. Marissa Mayer’s growth from a great Product Manager to being the CEO of Yahoo is a testimonial to it. So there definitely is a bright side for women as Product Managers.

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

Posted on

Role of a Product Manager

Ensure that the right things gets done in the right sequence

A product manager helps a company to achieve its goals by helping customers get their jobs done in an unique and delightful way, and getting customers to payin some form (money, attention, information).

Let me elaborate on the key responsibilities encapsulated in the above definition.

Getting jobs done: A parent purchases your app to keep her six year old daughter entertained over a three hour train ride. The parent did not purchase the app because it uses the latest technology or she liked how your app is designed/looks. A product manager must understand what “jobs” or outcomes a prospective customer is trying to accomplish. This can also be seen from the lens of solving problems. But I prefer the “jobs approach” as it provides a richer understanding of the context in which a product/feature will be used, why are they using it, what outcomes they are hoping to achieve, and what they need to stop using to begin using your product. A product manager must ensure that the team builds something compelling enough for customers to switch away from an existing solution that they are currently using. This framework is especially helpful in understanding your real competitors or alternatives that the prospective customer has to get a job done.

Lens of solving problems -“real problems”: A product manager must ensure she focuses the team’s effort on solving real problems that will help the company achieve its goals. “Problems” that are ignored are usually not worth working on. The pain killer vs vitamin framework is a useful for assessing the intensity of the pain/problem. Des Traynor’s perspective on“Making things people want”

Making things people want involves understanding a long standing human or business need and then using technology to:

take out steps

make it possible for more people

make it possible in more situations

Flawless execution cannot save a company/product/feature that chooses to focus on jobs/problems that nobody cares about.

Unique: Prospective customers will have an array of options to get their jobs done. The product manager must pick a customer segment and a dimension (like Amazon’s delivery of ordered items within 30 minutes) that is aligned with the most important outcomes/jobs that the customer wishes to accomplish. This decision is critical in ensuring prospective customers consider your product when they want to hire a product in a specific situation.

Trying to be everything for everyone or “unique” for the sake of uniqueness is usually a recipe for disaster. Choosing a dimension that is important the customer and has very little competition helps build a defensible business.

Delightful: While thorough and thoughtful attention to detail helps, Kathy Sierra’s talk on Minimum Badass User provides sage advice. Focus on improving the user’s life and/or skills. What “badass” powers does the user get by using your product?

“People don’t use your app because they like the app or they like you, they are using it because they like themselves, and they tell their friends because they like their friends!” – Kathy Sierra

Establishing reference customers is critical for scaling any business, and you will have reference-able customers only if you have delighted them while getting their jobs done, using your product.

Pay: In a business context, the product must generate enough revenues to grow and sustain the business over the long term. The product manager must be adept at picking a business model that captures enough value for the business to thrive and remain viable.

Another critical responsibility of a product manager is validating that the solution (product) that is built is actually helping the customer get their jobs done and delighting them in the process. Some product management frameworks mandate that the product manager must focus only the “problem space”. I strongly disagree with this specific recommendation. Validation of the solution/product that has been built is as important as specifying what to build. I am not advocating the product manager specifies how to build. Does that mean the product manager does not validate other critical decisions like validating intensity of a problem? No. I am specifically calling out this aspect as a product manager plays a crucial role in deciding whether to ship a product/feature based on this validation.

Summary: Prioritizing which jobs/problems to work on, which customer segments to target, which dimensions to compete and excel on, how to access customers, how to capture value, determining what will delight users, how to scale the business, and validating what is built are key responsibilities of a product manager.

Two other perspectives on the role of product management that I like are one by Marty Cagan

Discovering a product/feature that is valuable, usable, and feasible

and the other by Satya Patel

“Product management isn’t a role or a function, it’s a set of skills. Those skills help remove obstacles and grease the wheels so that the functional experts can do their jobs best. Product management also balances the needs of users, the business and the team and makes the difficult tradeoffs needed to keep pressing ahead. In that way, Product Managers are very similar to CEOs. Very few would argue that a company doesn’t need a CEO. Product managers are simply CEOs of their products. No organization should be without someone who has ‘product management skills’ and works to make everyone else’s lives easier.”

Note: Every interaction that a prospective customer or customer has with a company is viewed as the “product”. It is not just the physical product or the service that is provided. Examples: looking for information about the product on the website, reading the user manual to understand different options/modes supported by a specific feature, sending an email query to the support address.

Next Post: Based on this role definition I will cover skills that a product manager needs to posses to be successful.

Guest Post Contributed by Pandith Jantakahalli, Sr. Product Manager at Impelsys

Posted on

Startups and Product Managers

Who is a product manager and what does a typical development cycle with a product manager look like?

Product managers are often the most overlooked job descriptions in startups. The “let’s hack together” mindset is great but might not scale after a certain point. It becomes imperative that someone is incharge of defining the “what to build” part of the problem extremely well, keeping the customer’s problems in mind.

Ben Horowitz was right when he said,

Product Managers are the CEO’s of the products.

Good product managers think about the story they want written by the
press. Bad product managers think about covering every feature and being
really technically accurate with the press.

So who is a Product Manager? A Product Manager is someone who owns the product — design, rollout, user acceptance criteria, user adoption and in many cases revenue. And in many small startups, the CEO is the Product Manager.

Who does the Product Manager work with? Typically with the customers or with the key executives. The Product Manager translates a business vision into a well defined product that solves critical customer problems and drives revenue.

What does a typical development cycle for a Product Manager look like?

  1. Define the Vision for the product.
  2. Define the use cases for the product.
  3. Define the Modules, Release Defining Features and a UI Metaphor
  4. Build Wireframes — Use tools like Pencil, Balsamiq or just sheets of white paper.
  5. If the Product Manager owns the product, he or she must be sure that he is solving the problem that he set out to solve.
  6. Build a full HTML prototype that almost works (everything but the server side code) together with a UI Engineer who is familiar with UI design patterns, UI libraries and other UI components necessary to meet the UI look and feel. The look and feel if built for the first time might require a fair amount of effort. Subsequent efforts should use an existing templates and should be much faster.
  7. Limit the above steps 4-6 to 1-2 screens or as many as the team can build and release per iteration.
  8. Build test cases with the QA team. Verify that the screens meet
  9. Transfer over to the engineering team to get to code complete status.
  10. The product manager is involved in the code-bugfix cycle.
  11. Product manager then conducts the acceptance criteria and then
  12. Approve the features to be released into a production environment.
  13. Repeat the wireframing process through a new iteration through multiple iterations until all of the release defining features have been met.

The job of a product manager doesn’t end here. It typically moves into the marketing domain where the product manager might work with marketers / growth hackers in the organization to build the packaging for the product and take it to market.

This might mean that the product manager might build press kits, landing pages, talk to press and conduct a launch.

Further reading:

Product Managers: Who are these ‘mini-CEOs’ and what do they do?

Good Product Manager/Bad Product Manager

Posted on

The Atypical Product Manager – Nishant Pandey, Naukri.com #PNHangout

Every Byte Counts 

Earlier I worked as a field engineer in Schlumberger, providing Drilling Services. Drilling is a very high tech, and arduous task; whether it’s on land, on a river, on deep waters. My job on any rig was to determine the direction of the oil well and properties of the rocks we burst through – its density, its resistivity, its shear strength, its porosity. We did this via real time telemetry of data from sensors placed on the rig as well as from sensors that were sent many kilometres down into the earth. All this data came to our computers in bytes of 1s and 0s. We had to be rigorous in analyzing every bit of this data as any misinterpretation could mean the difference between finding oil or water.

The Atypical Product Manager

After working for Schlumberger for 8 years, I did my MBA from ISB-Hyderabad. There I met Hitesh, then the COO, and he hired me to Infoedge. Having a background in oil drilling and sales, my knowledge of the internet was limited. I wasn’t hired for any specific, well defined role. When I joined, I did  a bunch of assignments related to Online Marketing, TeleSales, Competition Assessment etc. After a few weeks of such ‘consulting type’ assignments, I was asked if I would like to head the Product Management team of Naukri.com.

My understanding of what a Product Manager does was next to nil. I assumed programming was an essential part of this role. However, Hitesh and Vibhore allayed my concerns, explaining what my role would be. I was told, by way of an example in a lighter vein, “If you leave Naukri.com to the Techies, it would look like tables of data, with very little aesthetics to it. If you leave it to the Marketing team, all you would see is banners all over the site”. Although this was clearly exaggerated, they went onto to explain that this means that the Product Management team acts as a pivot, to the Sales, Marketing, Technology and other teams, keeping the many teams’ expectations in consideration while evolving the Product in a way that benefits the users. This sounded interesting and it seemed right down my alley, so I was excited to take this challenge up.

Key Victories

The reason I brought up my experience as an Oilfield engineer is because it built a rigour to pay attention to details of planning and nuances of execution. Whether it is drilling for oil or whether it’s for improving an internet product, making logical, data based decisions and teamwork are key to success. Moreover, in both the jobs when you make a pitch to various stakeholders, the recommendations have to be crisp, strong and  factually correct. So, interestingly, I was able to bring learnings (a lot more than one would imagine) from my previous job and apply them to challenges here.

  1. Communication: The goal for any business is to increase the returning visitors. In our case the only way to achieve this was having relevant jobs for candidates and communicating them to our users in a manner that was effective and didn’t look like spam. Hence, we worked on every email communication to be crisp with a clear call to action. The subject lines, signatures, salutations, the contrast in colours, the font type and font size had to be well thought through. The team also brought about a complete re-vamp to many aspects of the site communication and interfaces, and we have sometimes seen a massive jump in our metrics just because of this.
  2. Transparency in information and no silo’s: Every stake-holder must be privy to the same information, and every one must be spoken to in the same voice with the same data. This has been one of the critical things that the Naukri product team ensures, especially in terms of decision making and dissemination of site metrics.
  3. Improving algorithms: Naukri has over 15 algorithms running on different applications, and sometimes you see 3-4 flavours of the same algorithm depending on which page you are querying from. The challenge of matching a CV to a job is that a CV, which consists of thousands of words needs to be matched with a Job Description, which also consists of thousands of words – and our algorithms have to determine which are the most important of those words that need to be matched, and which words are to be ignored. The search and match algorithms have in recent times changed significantly from the earlier versions of them. We have had fantastic results and this has been thrilling for our team.
  4. Growing the team: The up-curves in advancement in Naukri have been good because of the superior PM’s we have on board. It has reached a stage where the product team has become greater than the sum of its parts. One person cannot know everything about a product especially with a complex product like Naukri. So the only way to achieve effective results is to have a very strong group of 7-8 people amongst whom collectively every piece of knowledge is available, and that they work as a transparent team within and with other teams.

The Power Of The Marginal

I’ll just sum up with something Paul Graham talks about in his essay ‘The Power of the Marginal’. He states that “… outsiders, free from convention and expectations, often generate the most revolutionary of ideas”.” In my personal case I was an outsider to the internet business and that helped me contribute new ideas and ways. In hindsight, my exposure to sketching, photography, reading, writing and an interest in Psychology helped me appreciate the work that goes into the Design and Marketing of our product, and allowed me to contribute to it.  This automatically involves you with the other teams at a whole new level and leaves a lot of room for collaboration. Who knew hobbies and interests developed decades ago would help me shape my job? Hence, I feel a PM with a diverse background, someone who is as good with Divergent Thinking as with Convergent Thinking, someone who is as comfortable with artistic subjectivity as he or she is with logical objectivity, could be more effective than a PM with an only technology background.

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

If you have any feedback or questions that you would like answered in this series feel free to tweet to me: @akashj

Posted on

Data and User Experience: Two ends of the spectrum

Every product that you build has to be used by people.

This is irrespective of “who may pay for the product“. This is an often brought up topic of “User vs Customer“. And if the product is used only by machines and not by real people, then it’s perhaps best to call it “technology”.

As far as technology products are concerned, a significant factor of differentiation they claim and deliver on is by leveraging data about usage and user behavior. And in a product team, the cycle goes this way:

  • Product Manager thinks up the product (you can assume that in all these steps, others also contribute meaningfully, as product creation is both an intensely cerebral and collaborative exercise)
  • Designer helps visualize the user experience
  • Engineers code it and get it ready for prime time

The plot:

1. Roll out the current version of your product
2. Get users to use your product, engage with it and contribute inputs (read Data)
3. Collect usage and behavior data, analyze it and generate ideas for the future features
4. Design & develop the new features
5. Start from Step 1 again

If you notice, in this iterative and cyclical process, the two constants are Design new features (UX) and Collect more data. While this cycle goes on, imagine the various changes that happen to your company:

• People added/removed
• Infrastructure modified (change offices/locations etc)
• Technologies changed/added
• Investors changed/added
• Markets discovered/validated
• Pivots created/executed/dropped
• And the list can continue

But the core 2 tasks remain: Design UX for your user, Collect Data from your user, both of them aimed to improve their value proposition. This prompts me to call Data & UX as the two ends of the spectrum of building a tech company. It’s very interesting to note that if Data connotes Scale, UX connotes Empathy. To build a successful company, I imagine that one needs both Scale and Empathy and not just one of them.

What do you think? Let me know in the comments.

Posted on

Leveraging Customer relationships as a Product Manager

There have been epics written on ways businesses should be:

  1. Identifying customers
  2. Acquiring new customers from competition
  3. Retaining customers
  4. Cross selling and up selling into existing customers
  5. Leveraging Customers for expanding business

For a Product Manager, who has to deal with many internal and external entities, Customer is by far one of the most business critical entities that he has to deal with. And rightly so, since it’s the customers who not only pay for your product but help in innovation, evangelizing product and most importantly give you the credibility to make the right product / business decision and the confidence to stand by it.

Every organization has different dynamics around customer management. Hence as a Product Manager, once you get into a new organization you have to feel your way into the customer management dynamics. Let’s focus on some of the common trends and techniques used for successfully getting a handle on building successful Customer relationships.

1. Identifying Customers:

One of the first and the foremost tasks is to identify the customer. There are two types of customer:

  • Internal Customer: These can be folks within in your organization who use your product or service to assist your external customer or use the product / service on behalf of your external customer. As a Product Manager you should give their voice a significant ear, since they can not only share their experience but also be a voice for external customer. Another benefit is that since they are part of your organization you can leverage them for beta testing, brain storming ideas, hand holding external customer and even for evangelizing products
  • External Customer: These are your paying customer. As a company you have made a promise to them for delivering a product / service and that must be kept. You should categorize the customers in terms of their value to the organization:
  • Revenue (current and potential)
  • Brand value
  • New market beach head
  • New geo beach head

 

2. Initial Customer Contact:

Initial customer contact is a crucial point in your relationship with the customer. Hence it is critical that you do all the necessary research on the customer account prior to the meeting whether it’s in person meeting or on the phone. The per-call prep can help you gain insights into customers:

  • Business
  • Current issues
  • Temperament

 

As part of this initial introduction to the Customer, you must establish credibility by highlighting your relevant past experiences and listen intently by being the fly on the wall. One the key things to remember is that as a Product Manager you must align and fit well into the Sales team dynamics, since they are typically the owner of the customer relationships.

3. Basic Ground Rules for Ongoing Customer Engagement:

Once your initial introduction is done, managing the ongoing customer contact is delicate balancing act. A customer managed properly can help take your product to the next level along with its revenue.

  • You must establish basic ground rules:
  • Reviewing meeting agenda with the sales team
  • Sending meeting agenda in advance to the customer
  • Follow through plan after the meeting
  • Set up meeting success criteria
  • You have to be careful not to overwhelm the Customer with long and frequent meetings since it can cause confusion and delay in reaching your goal. This is especially true when you and your Customers are geographically apart. Crisp, succinct and to the point conversation is critical for ongoing communication with any Customer.
  • Remember the Buddha story about teaching Nirvana to a starving disciple? As long as the disciple was starving, there was no way he would have been interested in learning about Nirvana. Similarly, focus on the immediate needs of your Customer before offering him advance solutions. Once you solve Customer’s immediate business problems, he will be interested in working with you since trust in the relationship is built.
  • It’s critical to set expectations when you have conversation with Customers. Typically, if you ask customers to share their pain points, they will open the floodgates and expect those pain points to be fixed immediately. Hence before asking the Customer to open the floodgates, you should make sure that you set the right Customer expectations so that Customer doesn’t loose interest and let down. No one wants to tell the same story again and again, especially if your organization is expected to fix at some point. This same principle goes for sharing product and services roadmap. You should help Customers understand that documents like these are for confidential and for directional purposes only.

 

These basic principles for managing customer interaction will vary based on geography, industry vertical, business model, company size, number of products, product life cycle, etc. But, if followed consistently will take your business to the next level by forging long lasting relationships with your loyal Customers…

 

Posted on

Product RoundTable Bangalore @ Vizury Office

We had some very good hosts @ Vizury office and also joined by their product folks Shiju and Subra for the Product Round table that was organized last Friday. The other awesome people who were part of the event were Siddharth Ramesh (Exotel), Jose (Weavedin), Vinay Simha (Dfy Graviti), Sridhar (ex-Inmobi), Avinash Raghava (Product Nation), Nari Kannan (The man with experience of over 7 startups and currently working on a project for Barack Obama), Anjali (Capillary), Chandra (i7networks), Santosh Panda (Explara), Venkatesh (Insieve), Pandith (Impelsys).

The discussions revolved around 3 things in Product:
1. How to track growth & health of a product or Product Metrics
2. Product v/s Sales (When to listen to customer and sales person and building the feature)
3. Product Marketing

and 2 small sessions of Santosh explaining his re-branding story from Ayojak to Explara and Venkatesh about how they balance in a unique way not building before selling and working on product demo’s without having to build the features.

Sridhar led the moderation of the session and showed his secret sauce of a graph designed for Product decisions:

The graph helps Product folks take decisions based on a problem, and how ideally first level and second level product problems when probed can be solved by Education & Processes. This sort of product thinking gives more bandwidth to technology & product managers to focus on building the tech as well, apart from features as a solution to everything. It helps keep your product from being stretched into a services play.

Nari Kannan & Sridhar again spoke about how the health of a product and its metrics can be linked to the business metrics by the GEM (Growth, Engagement, Monetization) theory.

A lot of discussions around how sales folks like to ask fore more features, and how to decide what to build and what not to, but the graph helped a lot.

A snippet on the learning from Santosh’s Ayojak to Explara journey was that he communicated the brand change much in advance internally and decided to leave aside feature requests etc. and kept focussed on the UI/UX and internal communication of the change. It helped everyone realize that multiple massive changes should not be attempted together.

Venkatesh also spoke about how they develop new feature requests in a staging environment, and release it just for the customer in a prototype without pushing the code into the product, and ask him/her if they will pay for this and is this what they want. It is an interesting way to get a yes from the customer before getting your tech team working on something which might or might not sell.

All in all, everyone had some great learning’s, a few beers and cookies along with chai and coffee thanks to the Vizury team, and we hope to get some more Product Roundtable’s running consistently and involving more of the product companies to have cross learning’s via sharing best practices.

Posted on

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.

Posted on

Whats your product – Dabangg Or Paan Singh Tomar?

Image courtesy - graphicleftovers.com

As a part of my product management training, I insist on the importance of understanding of behavioral science while managing products. I am both puzzled and irritated when a participant, that is mostly an MBA educated product manager tells me – Viveck, can we skip to the section of how to write a PRD as these principles are only relevant to my boss, VP – Product Management. On the contrary, designers and engineers hardly have ever raised such a moronic concern and are solely focussed on learning. Another, one such idiocy MBA product managers display is the need for ‘certification’. More about certifications in another blog.

Irrespective of your level as a product manager, its important to know about these behavioral principles as only through constant practice can you become adept at applying these with ease when you reach higher levels. Contrary to the mythical belief of our MBA product manager, knowledge doesnt descend down from heaven as soon as you are christened the VP of Product Management. It takes hard work and consitent practice to apply what you have learned

Why is it that I insist on understanding behavioral science especially w.r.t Internet Product Management?

Internet is about dealing with market risks

If you were to rate the risk for an Internet related business – one of the highest risk will be that of the adoption of the market. Internet is rarely about creating a ground breaking technology like the search algorithm of google and is more about marrying the existing technology with that of a market need. Dropbox did not create new technology, neither did twitter or  Facebook – all they did us marry the market to the technology. Here is one of the good diagrams from Steve Blank.

Market is about understanding people

Understanding market is about understanding people. More importantly, their irrationality. Here is an example of product – market reaction

One of my favorite examples is Dabangg, the Salman Khan starrer in the year of 2010.

The movie was one of the biggest box office hits. In a recent flight journey, I was reading an interview of Akshay Kumar who (along with the folks from the industry) was extremely puzzled at the overwhelming success of this otherwise ordinary masala movie. It seemed that there was no takers from distributors for Dabangg post watching the initial promos. Make no mistake – I am not saying Dabangg is a bad movie, I am just equating

the unexpected success that the movie enjoyed with the usually storyline. 

09-paan-singh-tomar-090312

 

Contrast this with the year 2012, the relase of Paan Singh Tomar. Well scripted, extremely gripping and real.  

The box office nos are noway close to what Dabangg is. Dabangg did a collection of Rs 105 Crores in the first 10 days whereas Paan Singh Tomar did not more than 9 Crores. Isnt this confounding? Werent we taught that a better product, in this case paan singh tomar, should outdo their otherwise ordinary counterparts in the market? Isnt that how rational audience had to react?

The answer is the audience wont and more often they dont. The understanding of this lies in the tenets of behavioral science. I will cover this in my next part of the blog.

Why did I choose Paan Singh Tomar against Dabangg?

  • Similarities of a rural setting
  • Both revolve around an inconoclast – in this case the leading male character
  • The lead character is a rebel in both the movies in their own ways
  • Lastly one of the good movies in the recent past

Whats your take on this?

Posted on

12 learnings from the launch of Institute of Product Leadership – Bschool for software techies in India

Seems only apt to summarize our 12 learning’s on 12-12-12

#1 – ‘Kitna detee hai’ ?

Maruti car runs a campaign in India around “keetna deti hai” (means in local language – how much mileage will i get in?). The first question on the applicant’s mind was – post program will I get a better pay or shift into a company of my dreams. Very few (23% of them to be precise) reported that learning is more important to them than placement assistance.

My take – People seem to forget that getting inside is easier than staying & growing inside. On the bright side its good that we have companies willingly wanting to hire the first batch immediately on graduation.

#2 – “Code Centric to Customer Centric”

The idea of transitioning from being technology centric to customer centric does seem to resonate the most with individual participants who cited “Project Management to Product Management” as the #1 desired transformation – to be able to understand the customer and the business context of what they are already doing.

My take – Business programs can only be valuable if they accelerate that transformation. Knowledge dissemination cant be the driver!

#3 – “Badge is important”

The idea of getting a diploma or a degree is rather important as a take away from the program. Brand is clearly important.. Interestingly enough compared to “Guaranteed Career Path” this was voted lower though.

My take – With liberal badge printing machines in the country most hiring managers see through it and at best use as a filtering criteria.It is even less valuable for senior R&D professionals

#4 – “Have you done this before?”

Surprisingly (at least to us) companies who wanted to nominate people to the program asked this question more often than the participant themselves. Companies (both senior HR/L&D & Engineering leaders) as well as participants appreciated the fact that the curriculum is relevant and faculty is world class but the risk appetite for companies seemed to be lower than participants who pledged nominations for the “next” batch!

My take – first movers almost always benefit. That’s why the early bird gets the worm. The program’s pilot batch will have the best foot forward to establish a brand and move the offering to higher price points for next batch.

#5 – “Better seat at the table”

Most R&D leaders showed frustration around why they were not able to add value with their global partners and wanted to equip themselves with the right knowledge and immersions to be able to have a better seat at the table and enjoy broader responsibilities.

My take – unless people make an effort to understand the productizing process all those frustrations will continue to rise. Intent and ability to help are two different things!

#6 – “I don’t want to become a Product Manager”

Interestingly enough not all senior R&D managers (64%) wanted to learn the “business” & “customer” context to become a Product Manager, instead they wanted to differentiate themselves and build a better career path on the Product Engineering Leadership track with the role models being cited as CTO and Head of R&D.

My take – Product Management as a process should be everybody’s business to understand, playing the role of a real Product Manager not so much as it’s a harder role to play than one thinks!

#7 – Its better if its hard to get in

The moment they heard that only 20% of applicants will be selected to the program the value of the program went up by a factor of 2 (Price to Value Analysis)

#8 – Relevance of MBA to their Product Leadership Growth

Majority of the Product Professionals who had done their MBA from Top B-schools cite around 21% of the subjects/topics being relevant to them in their current role. 35% of them believe that the degree gave them the necessary break/promotion/new role.

My take – General Purpose MBAs (even from top B schools) are great for people who don’t know what they want in life and hence want to get the exposure to HR, Finance, Operations, Marketing etc. Institute’s Board have actually factored this in and designed the curriculum to map to industry’s expectations.

#9 – Influence Building skills are missing

Across 5 categories of the curriculum, leadership skills were rated 3rd most desired after Customer Connect & Insights and User Experience & Product Innovation. Within leadership skills leading by influence was ranked higher than other soft skills like negotiation, presentation, cross culture communication and conflict resolution.

My take – One’s Influentiality Index (II) is actually the biggest propeller for career path acceleration, functional skills for an average R&D product professional is actually fairly high.

#10 – Relevance is good but I want my exec education to be personal

Relevance of the program resonated overwhelmingly with the target audience but most also desired personal mentoring 1:1 with industry execs and a personalized leadership development plan with necessary psychometric assessments. Interestingly 92% have never gone through such personalized assessment at their company.

My take – I wish I had done assessments like MBTI, DISC, Product Leadership Influentiality Index (PLII) etc to really know my gaps and build a plan to bridge them faster as opposed to rely on accidental growth.

#11 – Free money – take it or not take it?

Several industry reports suggest that 26% of educational tuition reimbursement budgets goes underutilized with global R&D centers in India. Most (97%) desired to get tuition reimbursement from their company to pay for the program, however it dropped to 52% the moment it was disclosed that only self sponsored candidates will be offered placement assistance.

My take – With retention being the driver for some companies to sponsor education this is bound to happen..

#12 – Scaling Startups vs Large Companies

Management teams from both groups desire better product leaders (91% – Agree + Strongly Agree) however their approach of solving is starkly different. Global R&D Centers want a longer program (underlying theme being retention) vs Scaling Startups want a menu of courses to select from.

Would love to hear your thoughts – especially if you are a product professional wanting to accelerate your career path with atleast 8 years of experience or part of the exec management team who wants to develop strong product leaders in the India R&D center! More info at www.productleadership.in