Product Management Archives - Page 2 of 3

08/04/201407/04/2014

PeopleWorks – Selling Thought Leadership

I recently visited the office of PeopleWorks to meet Hemant Tathod who Heads the Product Management function.

Spin-off from the parent

Hemant chronicled the initial journey of the formation of PeopleWorks. It began as a need identified by Mr Ram, President & Executive Director of Crossdomain Solutions who was looking for a solution to cater to existing policies of Crossdomain without demanding tweaks their in current HR practices. During this process he realized this solution to be a product opportunity for Small & Medium Enterprises as target segment & initiated market research to validate. The research indicated that the existing product had low growth value but it also identified an opportunity that lay beyond. As a result there was a decision to break PeopleWorks away to focus on an opportunity for delivering cloud based HR workflow. A Beta product was created and validated with a handful of existing clients. During this spin-off they managed to maintain and upgrade 50% of existing clients.

Validate the product with customers

During this phase of building the Beta product, PeopleWorks team set a plan to develop customer insights through various means. Beta product testing, Focus group discussions and also direct gap analysis using inputs gathered by the sales force. The Product Management team, who also had sales experience, knew the value of insights gathered by the sales team and various other sources merge that into the product roadmap.

Push/Pull strategy for sales

While acknowledging that the cost of acquisition is high for a push-based sales strategy, PeopleWorks management’s initial focus is on generating conversions via direct sales. They are investing in search and social optimizations for building a pull-based sales strategy. There is Sales enablement piece with Objective to groom the sales team on how to approach prospective clients to make a successful conversion and Onboard them faster.

Under promise and over deliver

PeopleWorks Product team is very clear of the product capabilities, the focus targets and to only promise what is possible. It is better to openly back out of a prospect conversation if their needs are not feasible to fulfill. With cloud based delivery model it is very easy for clients to “move out” and migrate to other competitive systems. Acknowledging this is clearly messaging confidence in their product, interest in building trust relationship with client and a promise to be on their toes to service the customer. PeopleWorks has Implementation team to help transition of data for a new client from an archaic solution to their cloud-based system.

Sales & Consultant partnerships

Hemant mentioned that PeopleWorks engages Channel Partner’s to provide better reach and comfort to clients. Many sales companies have established channels in the market of HR systems. Additionally there are several HR consultancies that consult on best HR processes. Working with these consultancies & sales channels provides references which lead to shorter sales cycles than the direct efforts.

Selling thought leadership

One story Hemant narrates is that of Sales team attending to a lead of conglomerate with 300,000+ employees across the globe. The PeopleWorks team shared with the said Company their gap to address their large needs considering the global set. The PeopleWorks team then engaged said company management on discussion around best practices followed by the users of PeopleWorks and how Human Capital Solution can be automated to streamline employee management processes. Few days later the large group signed up with us to implement PeopleWorks for a group company with 300 employee users in India, prior to scaling up. What’s unique here is that the Sales team chose to lose a potential sale in the interest of maintaining a reputation as a thought leader in the space. This actually ended up building confidence in the client leadership and a potential trial phase. PeopleWorks management has taken this model further and initiated sales certification and boot camp training for its sales force. Importance is given to understanding the CxO business challenges, their thought processes, language to use with them and try to anticipate their needs and match them to the product capabilities if possible.

Summary of key takeaways

Continuously validate your product and value to clients. Don’t be afraid to make strong recommendations for better growth prospects.

Under promise and over deliver.
Sell thought leadership.
Leverage partnerships with existing sales channels or domain consultancies.

20/03/201419/03/2014

Product Management mantras from the 26th Playbook Roundtable

The 26^th playbook roundtable was held last week (8^th March 2014) at Delhi NCR and brought together over 15 startup and product practitioners to discuss and gain insights on some of the challenging aspects of growth and monetization in product companies. This roundtable was hosted at Eko India Financial Services office in Gurgaon, and was led by Amit Ranjan, Cofounder of Slideshare, and Amit Somani, CPO of MakeMyTrip. In a span of over 5 hours, a diverse set of topics were discussed. Prominent takeaways from the roundtable were insights on approaches to pricing, virality, growth decisions, pivoting, user experience etc. The following paragraphs detail the key learning from each of these above aspects.

Pivoting in a Business

Creating a successful company is essentially a search for the repeatable and scalable business model. To succeed in this search, companies should frequently make and test predictions about what will work in their business models. Businesses, no matter, which stage they are in are always pivoting. As a business, while you do focus on your revenues, but you also need to constantly keep thinking what will drive the revenue in 3 years from now and ensure that you slowly move in that direction. Of the so many internet companies, perhaps only a handful will survive 10 years. Amit Somani mentioned how MakeMyTrip is constantly looking at the next big thing. It started from a flight booking venture for NRIs to become the largest flight booking portal for the Indian market and is already evolving to cater to hotels and holiday packages. The next challenge for the company is mobile and ensuring that the company is successful in an increasingly mobile world.

Amit Ranjan talked about how often ventures have to 3-4 side projects or “distractions” that help you understand what will work in a fast changing industry and ensure you evolve to address these changes.

Moving from early adopters to 10x Growth

One of the best ways to achieve 10x growth after successfully validating your product and without spending too much or no money is virality. By definition, virality is designing and engineering your product such that it markets itself. A viral product derives much of its growth from its current users recruiting new users. A user could recruit another through a simple invitation (“Check out this product, it’s cool/useful/entertaining!”), or directly through using the product (“I want to send you money on PayPal!”). Virality is not an accident. It is engineered. Virality is more about width and depth. Amit Ranjan shared interesting insights on how the homepage of Slideshare during the initial days was designed for virality (with several banners and stickers to attract audience) during the initial days and when the portal was able to achieve significant growth, the homepage was redesigned for user experience.

Prioritizing Customer Inputs in a B2B Product

If you manage a product or service in the business-to-business (B2B) market, customer requests for features will be a regular part of your work. Requests come in through the sales team, service reps, and senior management, as well as directly from customers themselves. This makes it difficult for companies to decide which feature to include in the product or not. A good thumb of rule to decide whether to include the feature or not is that if 3 customers want it or a pushy a customer wants it and you can sell it to 2 more customers, then you should go ahead and include that feature. A key issue is to how do you know multiple customers have the same request? A common way is to utilize software which allows customers to post ideas, suggestions and requests. There are idea management providers that are good for this. Or you can user customer feedback sites. These asynchronous, always-on, open-to-all sites are well-suited for capturing suggestions.

In addition, you may need to check other areas. Your email often contains customer suggestions. Or you have a service ticket database you can check. Relevant knowledge will be in people’s heads, those who directly work with customers.

Also, it is very important to validate this feature. This can be done by rolling out first to your employees and then to few customers. This will help validate your thoughts.

Documentation and User Training

Generating user training manuals and videos can be a tedious job, especially for ERP kind of solutions, especially when the product is frequently undergoing changes. Also, the general trend seems to be that users have stopped reading trend. Even if people did decide to read the instructions, showing too many at once increases users cognitive load. Because users cannot read the hint overlay and use the app at the same time, they are forced to memorize the instructions and then apply them. Thus, it is more effective to focus on a single interaction rather than attempting to explain every possible area of the user interface.

Rather than generating documents and videos which will very soon become redundant, a better approach will be to have built in CTAs in the product to help/guide the users. This includes things such as built in FAQs (built using services such as Zendesk), using coachmarks etc. Presenting hints one-by-one, at the right moment, makes it a lot easier for users to understand and learn instructions. This interaction pattern has the added benefit of teaching the user at which point in the workflow these interactions or functions become applicable.

Making Sense of Data

As a product usage grows, enormous amount of data gets collected and sometimes making sense of the data becomes a challenge for Product Managers. It is no wonder that big players such as LinkedIn, Facebook etc. have large teams comprising of data scientists. Data crunching from this team of scientists even help the companies to validate the probability that a particular feature will be liked by their audience.

Product Managers are knee deep in the product and data can help take an unbiased look at the product, often yielding amazing insights and learnings. Data Analytics are important for one major reason: What you don’t measure, you can’t improve. Without knowing what the state of the system is, it is very hard, if not impossible, to do much to change or affect the system. You can, of course, make changes blind, but without analytics you will never know whether the system was changed or whether nothing happened. It allows you to see what is currently happening, make a change and see what effect the change has.

A good way to make sense of data is to have an hypothesis and then look for local maximas. Apart from that, product managers can apply operations such as segmentation, funnels and cohorts to make more sense of data. Over time, as the system changes and improves, the KPIs (and consequently the metrics) will change, which in turn leads changes in what needs to be measured. It is likely that new flows and metrics will be discovered that prove crucial to the system so whatever the analytics used, they will need to be continuously adapted to meet this change and keep you on top of what’s happening in your product.

Encouraging Users to Sign Up

For a consumer product, completely logged in experience versus a logout experience is a choice between distribution and engagement. Slideshare and Youtube offer a complete logout experience as users do not need to login to access the portal. Linkedin devised an interesting way to incentivize users to sign up. They show a glimpse of profile to users who then need to sign up to view the full profile. It is also imperative that the process to get users through the front door of an application and engaging with content needs to be as simple and seamless as possible if an organization wants to win and keep mindshare.

Increasingly a lot of companies are using gamification, but it is more geared towards engagement rather than acquisition.

28/01/201428/01/2014

Before you start with Growth Hacking

Building a product startup is exciting. Most startups look to raise capital early and investors look no other measure but traction to take their bets. This need for traction puts immense pressure on the founding team to grow their startup. That leads to implementing multiple tips and tricks to improve the key product metrics – most importantly to show traction to investors. Founders get into the so called ‘growth hacking’ mode.

Growth hacking is the new buzzword in the startup town. There is nothing wrong with ‘hacking growth’ – most of the tricks attempted in this phase end up being short-term techniques. They might work for a while, bring traction for a while (which might lead you to raise investments) but these techniques don’t help in long term and the growth is not sustainable and quickly falls off.

Startups tend to neglect the simplest rules of product management before starting with growth hacking. According to me, here are the 5 Basic Rules of Product Management:

User Engagement > Growth Hacking
Retention > Acquisition
Context > Activity
Own growth channels > External channels
Being Valuable > Being Social

A. User Engagement > Growth Hacking
Remember startups like BranchOut, Glassdoor, Viddy, Socialcam – that famously hacked growth through Facebook Dialog Feeds? Though they showed amazing growth curve initially, it soon fell off. Most users dropped off the product as quickly as they signed up never to return again. Reason – zero engagement on the product. Ensure that there are enough engagement loops on the product before you do any sort of ‘growth hacking’.

B. Retention > Acquisition
Acquiring users is the simplest thing to do, retaining them is the key. Any user acquisition technique should retain a good percentage of acquired users. Not just that., over a period of time the users who dropped off should be reactivated – there should be enough methods to pull them back – emailers / network effects / and so on. If the product has strong engagement features, retention is a easy task.

C. Context > Activity
Most products undermine the importance of context. In today’s world – anything that is not context is considered spam. The finest examples of a context driven product is Quora that lets you follow topics of your interest and helps you discover relevant content. Also important are products like Twitter (that lets you follow users) and Pinterest (that lets you follow boards) to build a information stream in context thats relevant to you. Think of context when you build features.

D. Own Channels > External Channels
Many startups focus on external channels for growth. Branchout was focussed on Facebook Dialog Feeds, Zynga was focused on Facebook Activity Wall, Viddy was focussed on Facebook Open Graph. Perfectly fine – if there are enough engagement loops and good retention strategy. However depending on external channels might not be sustainable – many startups hacked the Facebook Open Graph to get significant users – this led to users complaining about to the noise on Facebook wall, Facebook in return built many approvals / controls to prevent applications from spamming the users and giving users ease to block spam applications.

Large startups like Facebook, Dropbox, WhatsApp were completely focussed on driving growth through channels owned by self and had very little or no external dependence for growth. Don’t depend too much on external platforms like Facebook, Twitter, Google (SEO) for growth – build our own channels. Facebook’s journey of growth hacking is well documented. Also Dropbox as mentioned in next point.

E. Being Valuable > Being Social
There are also startups that focus on building ‘too-many’ social sharing features, expecting users to share almost everything and anything on to their social profiles (Facebook, Twitter, etc). Users are smart – they don’t fall in this trap and founders keep wondering why no social sharing happens. Instead of trying to be forceful on social, focus on being valuable.

Example – Dropbox, it was a very valuable product that had super methods to hack growth – by connecting FB or Twitter account with Dropbox and providing users additional storage space by asking them to spread a message to their social circle or invite email contacts.

Concluding Notes:
Can you hack growth first and implement these rules later? No. There are startups that hacked user acquisition and raised initial investment on traction., and later things did not go according to the plan. Not just startups, that leaves even investors wondering what went wrong after the initial impressive growth metrics.

Startups are about growth, no doubt. Getting Techcrunche’d (PR release), top position on Hacker News or Video that goes viral might bring one-time traffic boost / user sign-ups. You can get good amount of traffic by integrating with Facebook Open Graph, optimizing site for Google (SEO) or even paid user acquisition – but make sure that the product has enough engagement, retention loops, value and context to sustain the users you are acquiring!

You may hack growth., but you can’t hack success. Building the next billion dollar company is a big deal!

18/12/201316/12/2013

DNA mysteries of Products and Services

It has been an interesting coincidence on the last few occasions in different discussions and industry forums I participated in, they have attracted a good amount of the classic “Products and Services” in IT deliberation. As such, this is not a new debate. It is common to see patrons from the products world root for it by generating IP and for the services gurus illustrate how they are able to tailor deliveries as per customer need to make good revenues.

In the various roles that I have been involved in be it front line sales, to working with target customers, to addressing markets through the channel, or driving product management for products of different types right from enterprise to small and medium businesses that are deployed on-premise or delivered as a service; I have realized it is more than “this versus that”. At the face of it, running “product or services” businesses largely seem to be two different ball-games. They do have different DNAs. However, in addition to the different focuses that are essential on some aspects; these also involve some common influences that need to be capitalized upon. And no, it doesn’t end there. An important element of success viz the customer expectation is undergoing an interesting shift. A customer increasingly expects…a solution! They are neither looking for a product or a service in isolation, but instead for a solution that delights and delivers timely value. In this post, we will explore the characteristic differences—the DNA differences between IT products and services; and some common factors that have a bearing on the business opportunities and performance.

The landscape—A holistic view

Let us start with a holistic look at some key characteristics of what constitutes a product and a service. The marketplace typically includes an offerings continuum. At one of the two ends are pure-play products and at the other pure-play services with combinations in between. It can be illustrated as below:

The DNA differences—A closer look

If we take a deeper look and closely evaluate this in context of IT products and services, around which this post is primarily focused, it involves some common influences, but with distinctly different DNAs to run both businesses. The evaluation of key indicators across these businesses includes consideration for common factors, but with different approaches. For instance, both product and service type of offerings involve evaluation and use of technology, assets and resource planning, cultural bearings and so on. A comparison of DNA differences for some key indicators is included below:

Common influences—A quick digest

As we can see, there are some distinct DNA differences. For instance, meeting a market need versus single customer requirement; transactional approach versus relationship driven, internally focused culture and processes versus tailored to customer. At the same time, aspects like technology, people, and processes are the common influences that can either enable or inhibit effectiveness in either model. They serve both as an opportunity and a challenge! The previous section has covered how the approaches vary across indicators. Let us now briefly assess the common aspects that can greatly influence outcomes.

Technology: Technological advancements are constant. With every technological paradigm shift, right from main-frames to distributed systems to the cloud, with the change in technology capabilities available, businesses have looked at methods to leverage these for maximum benefits. So for a provider, irrespective of the nature of business, they have to constantly find ways to stay abreast of technological advancements to be in a position to lead the market or advise a customer with right solutions. For instance, if we take a look at one of the hottest shifts around SMAC (social, mobile, analytics and cloud), it is not prudent for either product or services companies to ignore those. Products need to evolve to cater changing customer preferences, interaction methods and deployment models. This is not just limited to product companies. These shifts need service companies to ensure their offerings weave these in to truly to ensure customer delight in-line with newer preferences.
People: One of the most significant contributors to the success of any business is the people assets they have. Knowledgeable, motivated, productive and enlightened workforce is needed for runnnig both products or services successfully. Ensuring the workforce it kept current with the market and technology demands and on the soft side ensuring they’re productive is of paramount importance. This of course is an obvious one. But going wrong with this could have the entire game go south even if all else is right.
Process: Processes are a great tool any company can have through which preferred frameworks can be pressed into action for a more consistent and repeatable outcome. These could be applied to internal focused activities like training and development, knowledge sharing, documented development methodologies (e.g. Agile, etc.), sales methodologies and so forth. Processes can help with managing OpEx for both frameworks. Similarly, they’re applicable even to external focused aspects like processes to demonstrate thoroughness of approach, for compliance and so forth. How far to adapt really depends on appetite and culture; which varies from company to company.
Success factors: While the measuring metrics might differ across lines of business, it is a fact that there is no better way to walk towards success than to be driven by results that ensure customer success and delight. This is an essential metric to keep track of that cannot be overriden or ignored in either business.

Looking at all of above, one can think of products and services as two separate circles having distinct DNA differences with some overlap of common influences. All of these put together, put organisations in a position to meet the need of tomorrow. Let’s take a look at an illustration that highlights these put together:

The Ultimate structure—Solutions shift

At the same time, given the economic challenges, the markets becoming buyer markets, general shifts in buying patterns, need to respond to businesses faster, and need to demonstrate value and return on investments (ROI), the focus is increasingly on the “customer” than just a product or a service that is up for offering. Customers today carefully evaluate every penny being spent. They expect to realize value from investments faster. Customers are tired of siloed approaches either by just having a product deployed and not having a working solution, or having a solution frame-work, but the underlying products not being stitched to deliver the value the customer expects from the investments made. Gone are the days where companies could deploy a product and take months or even years to tweak it to customer need. Or suggest a service without having their own skin in the game when it boils down to technology or products involved. Customers today expect product companies to not just deploy a product, but to provide a working solution tailored for their needs. Customers today expect services companies to have the required levels of expertize, coordination and relationships with involved products and technology stacks, to effectively tailormake a solution to meet their needs faster. They do not expect the ball to be dropped in either of the cases to have prolonged deliveries. Customers today are looking for working solutions. Customers today are looking for faster realization of value. Customers today are looking for a positive experience to respond better to business needs rather than being tied up with large IT projects. They need to be delighted—truly!

The shift is really towards using products and services together effectively to deliver effective solutions. Irrespective of their primary DNA, every company will need to evaluate how they can work out the entire DNA strand to have a solutions structure!

14/12/201312/12/2013

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?

Define the Vision for the product.
Define the use cases for the product.
Define the Modules, Release Defining Features and a UI Metaphor
Build Wireframes — Use tools like Pencil, Balsamiq or just sheets of white paper.
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.
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.
Limit the above steps 4-6 to 1-2 screens or as many as the team can build and release per iteration.
Build test cases with the QA team. Verify that the screens meet
Transfer over to the engineering team to get to code complete status.
The product manager is involved in the code-bugfix cycle.
Product manager then conducts the acceptance criteria and then
Approve the features to be released into a production environment.
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.

What Makes a Good Product Manager: Lessons from Doers

For solo product entrepreneurs and product teams that are caught in a vicious cycle of build, release, build release, we bring some insights from “doers” that will help them differentiate through the demanding skills of product development. Deep Nishar, who leads product management at LinkedIn, had said sometime ago that a product manager needs brain of an engineer, heart of a designer and speech of a diplomat. Is product management an art or science is an extraneous question. It is both and more. If a product manager can understand where code sucks and how to place a nice button to entice the user, his job is well done. It’s a deft left brain right brain play.

Indian product ecosystem is evolving and many product managers are learning on the way to make their successes and don’t ask heartwrenching slips, which anyway is part of the game. These first-generation product managers are just sowing their seeds of a developing ecosystem. When we asked some accomplished product managers who are part of successful product ventures in India—Amit Somani of MakeMyTrip, Ravi Padaki of Pravi Solutions, Shivakumar Ganesan (Shivku) of Exotel, Krishna Mehra of Capillary Technologies, and Shrirang Bapat of Pubmatic—as to what makes a successful product manager, the answers were varied and thought-provoking.

Key aspects of becoming a product manager

Krishna Mehra and Shirang Bapat are unanimous in their view that a product manager should understand the pulse of the customer. Mehra adds another element to the product manager’s repertoire – execution. Ravi Padaki takes a holistic view in stating the a product manager should understand the how business works, be creative in solving problems for customers that may not translate as features in the product, and be a great communicator, not just in listening to customers but to the market as well. Amit Somani demands insane curiosity, building capability, and knowledge of how to work through influence. Shivakumar Ganesan (Shivku) of Exotel feels the product manager expects the product to sell itself and works backwards from market needs to build a suitable product. He feels product manager is a misnomer and the correct term is “market manager.” Shivku brings out the creative plus execution aspect of a product manager when he says, “he is willing to write a hack to keep the elegance.” Aesthetics are important for a product manager whereas the coder just concentrates on architecture and design.

Attributes demanded: ability to understand customer pulse, creativity, curiosity, influence without authority, capability to build what market needs

Top three priorities of a product manager

Ravi Padaki is emphatic that shipping is the first priority. Iterating and scheduling releases based on feedback and market response follows. Krishna Mehra cautions against building without validation and product discovery. In enterprise market, building for wrong requirements means loss of cost and time, while customer feedback should be gauged quickly for consumer products. Focusing on customer experience is the first priority of Shirang. Amit bets on a big vision to begin with. According to Shivku, customer support comes first.

The second priority for all the five revolves around execution. While for Amit, understanding customer requirement and translating it into a product is important, Mehra focuses on the ability to work with the engineering, design and QA team to deliver high-quality product. Shirang takes it a step ahead to focus on communication between customer, product manager, and engineering, which again emphasizes on aligning customer needs to building the product. Shivku emphasizes on product-market fit, while Ravi bets on validating the product through feedback through all stages of development.

The third priority for product managers is taking several parts of the organization together to build a successful product. For Shirang, the third priority is fitting the non-functional requirements into the product. Mehra wants the product manager to drive customer success by working with other parts of the organization. Ravi terms it triangulating and prioritizing, which means synthesizing inputs from various parts, which the product manager likes some part of it or not. Shivku calls for inventiveness in creating a product out of ideas from the junk. Amit takes shipping, iteration and metrics to the end.

Three priorities: 1. Enlisting customer requirements/support, 2. execution and continuous iteration based on feedback, and 3. taking the organization along during product development

11/10/201311/10/2013

“We think more like Product Designers, and less like Product Managers” – Bharath Mohan, Pugmarks.me #PNHangout

(This passage is a summary of the conversation with Bharath Mohan. The audio transcript can be found here.)

Adopters of any new innovation or idea can be categorized as innovators (2.5%), early adopters (13.5%), early majority (34%), late majority (34%) and laggards (16%), based on a mathematical Bell curve put forth by Everett Rogers in his book titled “Diffusions of Innovations”. The book broadly suggests that if you have a product that is of value, you often times have to pave the path for the consumers to be the beneficiaries of this idea. It’s the product designer’s role to design how a product is used across the dispersion of users. This ultimately determines the principles of design and the features that your product consists of.

While I was doing my PhD in IISc, I worked on designing a myriad of algorithms for information retrieval. A typical internet user reads content that could range from currents events, such as the war in Syria, to topics as specific as Product Management. I’ve always dreamt of a system that can bring the most relevant information to a user – without the user searching for it. Pugmarks.me connects the context in which you are browsing through these articles by following the digital trails you leave behind. It then uses its context engine to recommend the next article it considers you should read packaged in a seamless experience.

Designing Pugmarks.me has been an exciting experience, which included research in algorithms, building a real time crawling and retrieval system, and constantly learning from users. We’ve followed some Mantras in our product development – especially because the product requires inputs from multi-disciplinary areas. Everything has to tie in, to each other. Nothing is known prior and has to be learnt along the way. A “product management” approach would not work. A “waterfall” model to design would not work. “Powerpoint presentations” would not work either. Our product management is less of “management”, and more of design and evolution.

The Pugmarks Mantra

Unlike Facebook or Twitter where the problem’s technology core is simple and scaling is complex, our problem’s technology core is complex akin to the likes of Google’s search engine and NEST. Hence, over the past 1.5 years our product has been opened to a smaller set of users which gives us data to refine the product further ultimately paving the path for a larger cross section of consumers to enjoy the benefits of the product.

Some of our Mantra’s are:

Be metrics driven: Once we analyse our features metrics we identify ones that are successful and bolster them to make these our ‘super class’ features. While we do this, we bin our users into “Fans”, “Tried but dropped off”, “First day drop-offs”. The ‘tried but dropped off’ is where we focus our energy on. We do data analysis, interviews and direct emails – to understand why they drop off. What we learnt is that they mostly drop off because of the “inconvenience” of a new product; either added latency, extra memory consumption, instability of the browser, etc. These reasons give us new things to work on and improve.
Usage versus Users: We are building our product with the goal that even if few users come to try out our product, they all stay back. Between usage and users, we prefer high usage between a small number of users over low usage in a high number of users. If our product cannot engage users for a long time, any amount of marketing will still not help.
Focus on real Virality: Virality is often confused with just having a Facebook share or a Tweet button, or slyly making a user talk (spam) about your product in his social channels. Virality for us is the inherent quality in our product which makes the user want to talk about it. We consciously ask ourselves, “What will our users want to talk about Pugmarks to someone else?” These viral loops must be strengthened and not social share buttons.
Constantly question your assumptions: In our initial iterations, we felt our users will be concerned over privacy. Soon, we realized that the paranoid would never use us anyway – even if we gave them a lot of control. The ones, who used us, felt we were not building good enough models for them. So, we moved away from user supervised learning to a completely automated learning system. We imagine our current user telling us, “I’ll tell you everything about me. Now help me in ways I’ve never seen before”.
Continuous Integration: We never take up features or tasks that take more than two weeks to launch especially one’s which require a lot of people and require extensive build times and planning. If you finish the code and if it’s lying unused, there’s an opportunity cost lost because that code could very well engage a user or maybe incite him to talk about the product to someone else. This is a loss for us, hence, we continuously integrate.
Own the full user experience, end to end – From messaging to user touch points to the backend algorithms: A user doesn’t appreciate information until it is delivered in a way that is useful to you and is needed by you. We obviously needed a team that was capable of building this experience end to end. Our team considers every aspect of the product, from the touch points to the user, how the product interfaces with the user and also how the product communicates with the user using the technology algorithm we created.

#PNHANGOUT is an on-going 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

13/09/201313/09/2013

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.

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.
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.
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.
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

02/09/201302/09/2013

Some Takeaways from the #PlaybookRT on Effective Product Mgmt: Applications and Benefits for Technology Startups and SMB

The fifteenth #PlaybookRT with focus on Product Management was held at PubMatic office in Pune. It was led by Shrirang Bapat (VP Engg at PubMatic). Shrirang set the stage for RT by sharing the importance of ‘What NOT to do’ which comes from years of experience. To accentuate his point, he shared a story of introducing handhelds in the market beginning of 1997. Through this story he explained the importance and process of getting into customer’s shoes when defining the problem and designing the solution. The message was clear don’t be Tech arrogant! Be empathetic towards your customers. Understand their pain points and solve them by creating simple yet elegant solutions…

After the setting the tone for the RT, Shrirang formed pair of twos in which each person in the pair would introduce the other person by sharing the following information:

Name
What you do?
What does your company do?
What do you expect to get out of the RT?
The person who had influenced the most?

This turned out be a great ice breaker session. Participants really got to know each other and understand each other’s perspectives. Answer to ‘The person who had influenced the most’ where interesting. Here’s what some participants answered:

Founder of Toyota – Kiichiro Toyoda
Father
Steve Jobs (3 nominations)
Jack Welch
APJ Abdul Kalam
Mahatma Gandhi
Wife
Leonardo Da Vinci
Rahul Dravid
Cousin
Kiran Karnik

The RT participants wanted to have a conversion of variety but related topics such as:

Product Strategy for Go To Market (GTM) , especially globally
Increasing product adoption
Scaling UX and Selling in Indian markets
Process for validating ideas
Feature prioritization process
Product globalization
Implementation of Product Management practices
Product Management in Start ups
Product Management best practices
Scaling operations and Product Management

After some deliberation the participants were divided into two groups:

GTM (Mentored by Aditya Bhelande, led by Sandeep Todi and Nitin Seth)
Product Management processes (Shrirang and led by Gaurav)

Each group got approximately 1 hour to discuss on the following lines:

Define problems
Measure problems
Analyze key issues
Provide specific examples
Recommendations / Solutions

After about an hour leaders from each group shared their discovery with all the participants. Here’s the summary:

GTM:

Issues:
1. Scaling globally
2. Customer segmentation and market validation
3. Spreading product awareness
4. Customer discovery
5. Creating trust with global Customer
6. Solutions

Market Discovery

Better analysis of user / customer traffic and leads
Competition presence
Availability of infrastructure for product usage
Language and cultural differences

Customer Discovery

i. Web PR
ii. Blogs
iii. Local community

Building Credibility

i. Local presence
ii. Local employees / consultants (for example using commission junction (cj.com) or shareasale.com)
iii. Travelling and attending conferences
iv. Customer case studies and having customers talk about the company

Product Management Process:

Problems:
1. Prioritizing features
2. Poor UX
3. Lack of cross functional collaboration
4. Lack of Product orientation
5. Managing roadmap
6. Solutions:
  - When changing feature priority think about why. For example are you changing the feature priority to get a new customer or to retain the existing customer?
  - Create a balance between time and resources. Consider the impact of cost of change in direction. If a feature if 3/4^th done, then are you better of completing the feature before changing the direction. Are you willing to give up that work that has already been done?, etc
  - When adding new feature think about technical challenges such as scalability and Customer facing issues such as performance impact.
  - Analyze if the feature is merely ‘gold plating’ or helping get new business.
  - Ask ‘Why’ to get a deeper understating of the customer / sales need to set the priority. Try to understand the impact of not building the feature.

These were some of the key take aways for the RT group that came from a very lively and engaging discussion. The group decided to meeting once a month to talk about various topics other than Product Management such as Sales and Marketing.

13/08/201312/08/2013

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.

12/08/201312/08/2013

“Social Commerce – Enabling trust and higher conversions in online transactions” – #PNHangout with Vipin Agarwal

In this #PNHangout, we spoke to Vipin Agarwal, who is the co-founder of enMarkit and an ex-VC turned entrepreneur, about his journey in conceptualizing the product, his team, the tools and the product management philosophy and what a typical day in his life looks like!

Give us a brief introduction to what enMarkit does.

Enmarkit comes from a combination of the words: ENabling and MARKETing. We offer product based solutions to merchants who want to start selling online without these merchants spending too much time or money on creating their websites or struggling to deal with outsourcing agencies. We offer simple plug and play solutions to the entire eco-system of companies, SME’s and entrepreneurs using a SaaS model.

We have two live products –

enMarkit FAST (Fast Anywhere Secure Transactions) Payments Solution – helps anyone start receiving payments online instantly. This solution embeds seamlessly on any given website, blog, Facebook page or any social media page.
enMarkit ONE Store – The socially integrated solution that enables anyone to create an online store within a minute. This web-store has payment gateway already integrated at no upfront costs, giving the merchant a ready-to-use storefront that he can start sharing with his clients instantly.

Besides these, we have a couple of products under development that would, we believe, go a long way to revolutionize the online commerce ecosystem even further.

How did you meet your co-founder and how did you bring this concept to life?

As a venture capitalist I was exploring bottlenecks that entrepreneurs and companies faced in the online transaction space and in the midst of trying to find technology enabled solutions that could solve this I had met Ekta, who was the Amazon head for market places in India. It took about 6 months of back and forth conversation with Ekta before we started. Finally we chose to tackle the online transactions space head on.

We took inspiration from the user behaviour when a person shops for something from a mom-and-pop store. We realised that the entire product discovery, transaction conclusion and post-transaction behaviour of a person in real world is not reflected in the current transaction models of websites today. Buying is inherently a social phenomenon – and yet Social Commerce has distinctly been untouched in all e-commerce business models today.

It is very common to find founders juggling multiple roles in the early stages. What role do you play when it comes to product management?

In my current role I interact with multiple teams and different kinds of customers to bring our product to life. Although I do not have a background in coding, I do have a very strong opinion of the product features that come over from the use case scenarios laid out by interacting with our customers.

With feature additions we constantly communicate with the registered merchants on our platform to get an idea of what their requirements maybe. We usually break our customer demands into two buckets, soft and hard. Soft requirements are minor changes which can be made in our user interface, which improve the user experience and aesthetics of the product. With hard requirements, that are more complex and require a larger change in the product itself, we consult with the front end and back end teams to ensure the changes roll out smoothly, these could be issues such as improving load times, etc.

It’s interesting to note that some of the biggest critics we have for the product are the internal team-members! Pitching an idea and getting a go ahead is one of the biggest hurdles our product has to cross even before we even start the test marketing campaigns. The benchmarks set by our team are very high and that reflects in our products as well.

When did you know enMarkit was a market fit?

I had personally made over 2000 cold calls, talking to merchants and demonstrating a prototype to target customers before going whole hog on product development. Even though our product was in its early stages, we received tons of feedback from our users. Out of the 800-900 people I personally met, almost 70 people had actually committed to using our product after it would be ready. Once we knew that we had their support, this encouraged me to continue building the product further. After adding the social commerce features in our future iterations the market for us grew larger.

From 2012 to 2013, your product must have scaled extensively. How did you ensure the product and teams also scaled the right way?

EnMarkit started off as a social commerce platform which was built with direct contact to our customers. How we ensured continuity and evolution of the product and teams was by not throwing all the features on day 1. We request for a feature, build it, get some feedback and if it does not work as planned, we junk it. It was this type of ladder approach that has allowed us to build our portfolio of products.

What has been your most challenging problem and how did you tackle it?

Our product development philosophy has always been to build, evaluate and either junk or deploy the feature depending on the feedback we receive. Some-times junking the product affects the team morale, as the team may have spent time and energy building it. The solution I’ve found to this is to make the team understand that even though the work was great, the market wasn’t ready a feature like this.

What are some of the tools you use to maintain communication between the tech, design, business and sales teams?

There are various teams that work on various parts of the same problem, so it’s usually my role to maintain these interactions between the teams and keep the teams in synergy. Team management internally is always a challenge.

I keep a Gantt chart with me to keep a track of the timelines of the proposed and actual build times and ensure that is matched by the team. I also ensure that if a task is a road-block for another task, that timelines are maintained so that there isn’t a delay.

Some of the tools I do this with are Trello(for project management) and although very basic we use Google Docs and Excel sheets track progress.

Could you briefly tell us what a typical day for you is like at enMarkit?

Before, I get to work, I usually allocate a little bit of time every morning to catching up on the latest news even before I leave for the office.

After reaching work, I allocate some time every morning for catch up meetings with my team. We evaluate the work we will do today and how the backlog looks like.

Around lunch time, we usually take a little a little longer break of 45 mins. We usually discuss all the industry news between the team.

Post lunch, I usually allocate a couple of hours to talk to our customers.

Towards the end of the day is when I sit with the many teams again, often getting into a detailed conversation of the progress made today.

How do you divide your time between: executing your current tasks b) planning for the future c) emergency

Since it’s just the first year of our product, we do spend a considerable amount of time in firefighting. I usually plan for the future with my co-founder Ekta to evaluate the roadmap of our product and what should be communicated with the rest of the team.

Where Ekta and I help each other out, is that I work as a product manager/salesman with a lot of ideas and demands for feature requests and Ekta is usually adept at giving me an idea of the challenges that we may face in implementing these features, and also the estimated time it may take for the team to do it. By the end of this meeting, we usually end up with a list of tasks in terms of priority that can be handed over to the teams.

Any advice for other product managers?

I think product management philosophies vary from company to company, and I would suggest each product manager to use tools, styles that suit his/her personality. There’s no one mantra that fits all. The longer plan is balancing the requirements of the customers and the capabilities of the team.

Editors Note:

Every member of the product team is important. To succeed, a company must design, build, test and market the product effectively. That said, there is one role that is absolutely crucial to producing a good product, yet it is often the most misunderstood and underutilized of all the roles. This is the role of the product manager. #PNHangout is an ongoing series where we talk to Product Managers from various companies to understand what drives them, the tools they use, the products they work on, how they go about their day 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

24/07/201322/07/2013

Leveraging Customer relationships as a Product Manager

There have been epics written on ways businesses should be:

Identifying customers
Acquiring new customers from competition
Retaining customers
Cross selling and up selling into existing customers
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…

19/07/201318/07/2013

Don’t try to solve every customer problem by a line of code.

My First playbook roundtable. iSPIRT’s first initiative at Hyderabad, was a 4 hour insightful RoundTable that was organised by the ProductNation free of cost for the attendees, which most Hyderabadi entrepreneurs gave a miss and are sure to be regretting the missed opportunity and the learning possibility that it offered.

Sridhar Ranganathan, ex-VP of InMobi, a Product Guru and Aneesh Reddy, the CEO of Capillary Technologies, which is in the business of providing mobile-based customer acquisition, tracking, and loyalty business, were the key speakers for the day .The first half of the session was mostly participants- driven where each of us were asked to share our day-to-day stories at work along with our expectations from the workshop.

Below were the most common challenges that emerged from our discussions:

How to validate the need for a product?
How to prioritize from the features wish list?
What is the exact role of a Product Manager to drive successful product deliveries?

Validating the product need

Sridhar began the afternoon session by saying that, “The best way to validate the need for a product was constantly interacting with the customers and understanding their requirements.” He said there are 2 primary things for a product startup to be successful in the long run. One is Speed- wherein it is important for start-ups to be iterating faster as its always better to Fail Fast and recover quickly.

The second is to be data-driven wherein start-ups should be religiously looking and researching in terms of numbers both externally and internally .He recalled a popular quote, “Data is God and code is only a messenger”, which was truly an eye-opener as it made me realize the importance of constantly looking at data and then using that to validate the need of the product.

Aneesh shared a few of his real-life examples on how during their initial days at Capillary Technologies, they had spent over 6 months talking to every store owner be it big or small, to understand their needs and how they literally changed their product idea thrice before conceiving the final version. He also said that listening to customers played a prominent role in shaping the product rather than merely selling. He also spoke of how Capillary mainly stuck to one mantra i.e.- “Locking down on the cheque with the customer even before building a feature for them,” which not only drives a sense of stickiness and commitment with the customer but also ensures the right customer need is addressed.

Priortizing from the Features Wish list

This is by far the most common challenge faced by all of us today, which Sridhar strongly advocated by highlighting the need for PMs to start questioning every feature-benefit ratio in order to prevent any feature overload. He also stressed on the need for every PM to evaluate if every feature was designed for the ease of the end user. He added that it is important to add features in a disciplined manner and remove the excessive features ruthlessly. Bottom-line being – “Don’t try to solve every customer problem by a line of code.”

Aneesh also shared on how Capillary builds prototypes and demonstrates them to customers to ensure if the customer’s wish list has been fulfilled or not and that this has helped Capillary to keep the fine balance between what their customers are looking for and how the future of the product would shape up.

Role of a Product Manager (PM)

Sridhar began asking each of us to define what we considered the role of a PM to be and after everyone was done presenting their respective viewpoints, he mentioned the below as some of the qualities he would expect a PM to possess:

Empathy towards customers – the willingness to engage, understand and appreciate customer needs.
Confidence to have a point of view
Ready to build a product for the future
Culture of experimentation and being data-driven

Personally what I considered the best piece of advice for PMs is, “to be responsible for the Outcome and not the Output”. This actually accelerates the need for PMs to question every effort for a feature request and evaluate what would be its ability to generate revenue.

Overall, it was an immensely insightful session. I would also like to thank Sridhar for taking time out from his busy schedule to enlighten us. Huge thanks to Aneesh for being extremely patient and for responding to all our queries.

I highly appreciate the efforts of Avinash to create such a splendid product management session wherein we not only get a chance to meet/network with product gurus but also help us rethink our working strategies. Last but not the least, I would also like to thank Pramati Technologies for being an excellent host for this Roundtable.

Eagerly looking forward to the follow-up session soon!

Post Contributed by Thulasi, Associate Product Manager at Versant Online Solutions Pvt Ltd and can be reached at thulasi(at)moozup.com

17/07/201316/07/2013

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.

10/06/201310/06/2013

Product Manager, or Product Experience Manager?

In my last post Experiencing the product, or productizing the experience?, I talked about my experience with SiteZ and how their overall experience left much to be desired even though the core product was good enough. In this post, I will try to analyze things that went wrong which shouldn’t have.

Here are 5 things that went wrong for SiteZ if I look from a customer’s perspective:

They misled the user about the time it takes to register.
They didn’t allow the user to abort the registration attempt gracefully (which left the email address behind and created rest of the mess).
They were not forthcoming about who is sending me these spam emails (the email address was hidden with a display name that was the advertiser’s).
They exposed a feature to me (unsubscribe) which didn’t work
They didn’t give me an easy way to delete my account – emails bounced, UI didn’t have a button to delete, etc.

It is easy to jump to the conclusion that the feature designers have a malicious intention: somehow get people’s email id and keep spamming them. However, let’s assume that is not the case, and that this is a case of incremental features ruining a product. With this assumption in mind, let’s proceed to analyze how each of these situations came to be:

Misleading ad – Assuming it was not intentional, there are 2 possibilities:
1. Marketing person would have asked someone in products about whether it can be done in 30 seconds, and someone said yes.
2. Marketing person asked to tweak the flow to make it finish (with basic details) in 30 seconds, but the development team didn’t do the work and instead reused the longer flow.
No graceful registration abort – This is purely a feature design or prioritization issue, probably they didn’t think abort is an important use case.
Spam mail identity – I think the assumption would be that these mails go out after user has agreed to be spammed, so they would know (this information is anyway mentioned at the bottom of the mail in small fonts.
Unsubscribe not working – Again, feature prioritization issue. Not having unsubscribe button is probably illegal in such spams, so the next best thing was to not code the functionality.
Can’t delete account – A feature prioritization issue. Account deletion is usually an expensive operation (complicated to implement and get it right, and heavy on processing) and so someone somewhere decided it was not important.

A question that comes up: are we talking about one feature, one product, or one experience? Should the feature designer of registration flow worry about spam mail identity? Aren’t these very distinct features?

Yes, they are indeed distinct features. At the same time, they need to co-exist peacefully, without causing troubles for each other. SiteZ is one big product, which has multiple features in it which need to plug into each other, and play well with each other. However, if we say SiteZ is a product, it becomes hard to explain #1 above: who should be responsible for advertiser misleading the user. This is the reason why I would like to think of SiteZ as one big experience. Advertising is just augmenting the experience, or in some cases act as the invitation to try the experience. If a restaurant’s brochure misleads the customer and entices him with a 30% discount, which turns out to be only 10%, it is still a problem for the restaurant.

So who is responsible for SiteZ product experience? Enter Product Management team (see this discussion thread too). I would like to think it will be Chief Product Officer or VP – Product Management who has ultimate responsibility for the experience. Is it fair to product management team to have such a broad charter? I think it is fair, because the organization needs it and there is no group better positioned to do this.

To recap, here is what we have established so far:

SiteZ had multiple features and services dysfunctional which combined to give a terrible overall experience.
Even though they are diverse features and services, in the interest of the customer, overall SiteZ experience needs to be treated as one big product experience.
The group that owns this one big product experience is Product Management team. They are in the best position to do so

In the next post, we will see how a product management team should have operated so that such issues can be minimized/avoided. Stay tuned!