Posted on

When sales hijacks your product roadmap

Hey product manager, let me remind you of that time when you had the perfect roadmap for the market. You had it all sorted out (finally!) with engineering and were clear about what you’d build. Your teams had already worked on a few sprints and you felt that this time, you’d be able to get the product right.

when-sales-hijacks-your-product-roadmap

But then, your sales person turned up and said ‘I’ve just promised feature x to the client. We have to build it.’

You gnashed your teeth and got into an indignant fight.

The sales person just made your carefully crafted product roadmap look pointless.

How could he do this? You had just sent out your roadmap last month and said this is what he was getting. Why does sales always do this? Why can’t they just sell what you have, instead of pushing for what you don’t?

You take it up with your management, and maybe even the CEO, but finally are told that this client is just too critical, and you will have to build what the sales person wants.

You grimace, and feel all your passion drained out. Ok, you think, I’ll do it, but under protest. It’s my job to get it done, but it’s no fun anymore. Maybe you should just look for another job where they trust product managers over sales….

Let’s break out of the reverie. This is something that happens in a lot of organizations.

Most product managers have an ambivalent equation with sales. They need the sales team to bring in revenues, but hate having to accommodate what the sales persons ask (and always at the last minute at that!).

Is there a way out? Can you safeguard your product roadmap from mutilation?

To be honest, it depends on how your organization is structured and power equations within. But there are things you can do as a product manager to prepare for something like this.

Learn how sales works

A large number of engineers turned product managers look down upon sales as a necessary evil. They’re far more comfortable in the deterministic universe of building a product. Sales seem to be a profession for smooth talkers who care only about their numbers and not about the intrinsic product itself.

Unfortunately, this worldview makes life difficult for all involved, but is like a self-inflicted wound for product managers. You can complain about sales around water coolers all you want, but it’ll help more if you learn to appreciate how sales works.

In most of my product manager trainings, I ask product managers and aspiring product managers if they have worked with sales earlier. Many say that they’ve just accompanied a sales person on a customer visit. Often, they would be briefed by the sales person just before the meeting, and requested to not comment on anything beyond the demo. ‘Leave the relationship part to me,’ the sales person would say. If, during the meeting, they strayed from the brief, the sales person would try gesturing frantically to not say something that puts the deal in jeopardy. They usually walk out thinking that they should just send a junior the next time for the demo.

In my experience, I’ve seen that good product managers have a great understanding of the sales process and see themselves as team players in getting customers to choose your product/solution.

But I also find that most product managers have only a vague idea of how sales works. Sales is also a process, and most good sales folks have a keen understanding of how to get started in the market, generate leads, convert leads into conversations and go through the consideration-preference-sale process. Sales, especially enterprise sales, is a lot more strategy & structured approach than just numbers.

My recommendation to product managers who haven’t been through a sales cycle is to get a buddy in sales, and understand how they work. Not only does it make it easier to talk to them when it comes to client asks, it often gives surprising insights about how your product is used and/or what competitors are building.

Have different versions of your roadmap

Many folks are surprised to hear that you should have different versions of your roadmap. The sales team often uses the roadmap to sooth client concerns on whether your product/firm sees a long term view for something they need to invest in.

If you have the same roadmap that your development team uses, you risk the sales team aggressively committing to features to win the deal. Often, clients are speaking to multiple potential vendors, and there is risk of competitors learning about your product roadmap. There is also a risk that if the client signs off on a deal based on your roadmap, you have very little slack if things go awry (don’t they always?).

It often helps to have a ‘light’ version of the roadmap for the sales team to discuss with the clients. You could share the development roadmap in confidence with sales, but insist that only the light version be seen by clients. That way, the sales person also knows that he can reach out to check if he needs to share something from the development roadmap with clients on a case-by-case basis.

Negotiate

Most product managers know the art of negotiation with engineering teams to get them to agree on what to build. But good product managers also know how to negotiate with sales teams.

What does this involve?

Often, it means having the right amount of flexibility in your roadmap. Don’t look at yourself as a ‘mini-CEO’ who has to call all the shots for the product. At the other end, have your viewpoint that’s not based on what engineering can build or what sales tells you they can sell (this is why it’s important to know your customers well).

I’ve been lucky to work with sales folks who respect a well-articulated viewpoint on why a particular client ask will take the product down a path that will make it difficult to adapt for other changes later.

These conversations take the path of ‘how do we make this deal work?’ What usually follows is a negotiation on what we can tell the client, even if we can’t fulfil all his/her asks. This helps build a joint pitch on what we think is best for your business.

This doesn’t always work, but the process of negotiation with the sales teams often help build respect for your capability and reasoning as well.

Another factor that I’ve found helpful is to have a strong list of priorities for your product, and areas where you can be flexible. That helps in the give-and-take of the negotiation.

You may not always be able to prevent your roadmap from being hijacked, but you can minimise its impact with this approach. I’d love to hear your thoughts on this topic in the comments.

 

Posted on

Product Management Roundtable For Startups by iSPIRT In Pune. #PlaybookRT

After all the missed opportunities of being at a PlaybookRT by iSPIRT, I finally made it to Pune last weekend for the roundtable on Product Management. Amit Somani and Rahul Kulkarni conducted the session. While I can’t do justice to all that was discussed at the session, I am translating my notes from the Roundtable into this blog post. After sharing some of our product dev insights in my last post Learnings From Building A Consumer Facing Web Product, this was a good opportunity to become a sponge and soak in all that I could manage. 

As a startup founder who hasn’t previously worked in a product company, starting a product business is tough. And being a CEO with no technology background, doesn’t help the mix either. The challenges for building an internet product for me may be more than the average amongst the ones attending this Roundtable, but product management is still a tough beast. Understanding consumer needs, building a product around it, figuring the right metrics for your business, measuring it and iterating is puzzling for anyone, specially given the fact that we are always chasing a moving target.

2014-11-08 14.15.57To give you a taste of how things play out in the real world:

When we started PriceBaba back in 2012, mobile apps were a good to have, desktop traffic was bulk of Internet usage and little did i know that India is on the verge of such massive investments in online shopping. Over 2 years later, the story is very different. Mobile is huge (both web and apps), online shopping is real and consumer Internet in India and the investment landscape which was looking slow between 2012-2014 has picked up crazy momentum.

For a startup that is bootstrapped, at an accelerator or even seed funded stage, getting the product market fit, raising funds to survive, hiring good techies and dealing with an uncertain market which is changing fast is a daunting task. If you add to that the learning curve involved to make things successful, you would know why I appreciate this Product Management PlaybookRT by iSPIRT so much.

The Product Management #PlaybookRT

Amit and Rahul kicked off the session by helping us define our product vision (and separating it from the company vision and mission). We were asked to make a 30 sec pitch by each of us on our product vision along with two things that we would never do. Both Amit and Rahul played devils advocate and helped us think through what we are doing. Learning: A quick dipstick to check if your product vision is well defined, ask employee no 20! If they can define it well in your (founders) absence, then you have set your product culture right.

Stack rank your requirements. What is the single most important thing you? Rahul suggested us that things can’t move forward till we stack rank our priorities. We must know what is the most important thing that we do. A somewhat heated discussion was on how important the user interface of a product is for being successful. Should we fret about having the best UX out there or build a product that is very compelling, offers a better price than competition and delivers what is promises reliably? To cut short on what could be a day long debate, here are two independent bits I picked up from our facilitators. i) If you are offering something that no one else can, your consumer will also use a command prompt to get it. ii) Your Apps UX is much more important than what it was a few years back and it is getting more and more important by the day. But that may not be the lone factor in getting a winner out there. That said, don’t purposely try to build a bad UX 😉

The user experience is not just defined by what the user does on your mobile or web interface. It is every touchpoint that the consumer has with your brand / service. It is the whole packaging of what a user goes through. For a e-commerce site it would go down to the professionalism and courtesy of their delivery boys. Similarly, when taking a view of product, the challenge isn’t always about getting that killer UX designer to work on your mobile app. It is really defining what your product does and how.

Each of us got enough time to define our key metrics and find ways of measuring them. With my experience I can surely tell you that it is indeed true that which ever metric you track on a day to day basis, improves quite magically 🙂

Tips on collecting feedback & effective product management: 

  • Take feedback from your extreme users. Either the ones who are very naive and would ask very basic questions. Or from the extreme users who would want every pro feature out there
  • Group users by commonality. Set goals for users who perform well. So track a users life journey within your app, figure key milestones and set them as goals. Optimize for these goals. So if you know that a user who completes Level 1 of your game, is most likely to play till Level 4, try to optimize such that you acquire users who will complete Level 1

Apart from the evergreen Google Analytics which is great for averages, tools like Mixpanel, Kissmetrics and Wizrocket are great for digging into specifics. You may want to give them a spin. You may also want to check Dave McClures talk on Startup Metrics for Pirates. 

playbookRT

Hiring. The Big Deal. 

So the tired entrepreneur in you is thinking already, when can I hire someone to take some of my money and all my product problems? Well, well not so soon! Product Managers come in various flavours and to begin with, YOU are the PM. Hiring a lead product manager is tough and transition is not easy. You need folks who are curious, bring product insight, are analytics, can be strategic and can work with really smart engineers. This is an individual that blends great communication skill and simplicity. So where do you find such a mahapurush?

Amit suggested a good strategy of hiring young grads and train them to become good PMs in a year. They will love the opportunity at the start of their career and won’t burn a big hole in your pocket. That said, a dedicated product lead will take over the duties from the founder(s). This would ideally happen at a later stage for most of us attending the Roundtable. The three flavors of Product Managers are:

i) A Project Manager who will get your task list executed

ii) A product manager who will get the job done but won’t give a new direction to the part they are leading – the CEO holds the strings. Also example of Windows OS where changing one aspect as per will of a Product Manager won’t fly, it would need the to go hand in hand with the whole OS

iii) The Business Owner – Give this product manager your metrics and let him/her chase it down for you with full ownership

^cheat sheet: Google for questions asked to Product Managers at Google / Amazon / FB 🙂 

2014-11-08 14.22.30Best Practices For Product Development: 

i) The Amazon Approach – Write a press release before starting the product development. Also read this by Ian McAllister of Amazon:

ii) Before you launch the product, predict the no of users your new product / feature would have for the next week & month. Define the usage metrics

iii) Have extreme clarity in goals, let people make mistakes but own the job

iv) Questions to ask yourself – Is this world class? Can an engineer look this up and build it in 2 days? Why are you uniquely positioned to do that?

Also appreciate if someone else has users and learn as to why they have users for what they have built. You can learn a lot from that. Eg: Google & Apple learnt about good features that would eventually go into their OS by looking at some trivial but popular apps on their App Stores.

Books recommended by Amit and Rahul: 

  • The innovator’s dilemma by Clayton M. Christensen
  • Start with why by Simon Sinek (also the TED talk by Simon)
  • Profit from the Core: Growth Strategy in an Era of Turbulence by Chris Zook
  • Only the Paranoid Survive: How to Identify and Exploit the Crisis Points that Challenge Every Business by Andrew Grove

2014-11-08 16.26.16

Posted on

The evolving roles in product ecosystem

I was catching up with Avinash (@avinashraghava) earlier today and we were chatting about product startups in the country. If you’ve been in this ecosystem, and seen the evolution of product companies, some interesting changes happened over the past few years.

Back in 2001, at AdventNet, the Product Manager role was created, and so was the Usability Engineer role (which were primarily UX Designers). There used to be debates about project managers and product managers and I’ve had a chance to see these debates well into 2007-08.

While interviewing with Yahoo in 2004, the recruiter was not quite sure of what they wanted me to highlight (since i didn’t come from a software programming background) and asked “have you taken any short courses on programming languages, that you can highlight in your resume?”. I had to politely decline modifying the resume – it would’ve also meant not highlighting the UX-related work I’d done while at AdventNet. Guess that was a time when the tech world was still coming to grips with the need for Product Managers in product companies.

Those days, Yahoo had a good bunch of UX Designers, and not enough companies felt the need to have good UX Designers. I was lucky and fortunate to work with some very smart designers while building products such as Yahoo! Maps, Yahoo! Local etc. Those days, there were conversations about 2-pizza teams (at amazon), 3-people teams (PM-UX-Dev at google) and emerging agile teams.

By 2006-07, the ecosystem had recognized they needed product managers and many product companies started looking for pm talent. And they were getting started on hiring User Experience Designers.

When I moved to InMobi in 2008, we built the PM team, the UX team and also realized that the way to build great products was by leveraging the data we had, to generate analytics and insights. Helping the user with understanding of what’s happening in the system with respect to their work/needs was a great way to get the user engaged with the system. This starts initially (at low data scale) with basic reporting tools – tables, charts etc. As the data grows (and boy, does it grow fast!), these tools have to evolve into more sophisticated ones. The decision systems also crunch lots more data to generate their outputs. And who better to help with those than data scientists.

By this time, most companies and the recruiting world were familiar with and looking to hire UX designers.

Getting a lead on understanding data and building newer insights helps Product Managers think about smarter ways to solve user and business problems. It also helps UX Designers to visualize newer ways to portray information as well as overall experience. It’s no surprise that companies are now looking to hire Data Scientists quite early in the game, especially the ones that want to build world class products. The VCs are also paving the way with roles like Data Scientist in Residence.

I did a small experiment last year, looking through the websites of various companies in the data services spectrum (data warehousing / analytics / data consulting etc). I went through their archived websites of 2008-09 and saw that terminology such as “data warehousing”, “data analytics” etc had given way to “Big Data” starting 2010. I think this is an important trend to understand – tech businesses are prolific at creating data. To leverage that, they need a pretty significant set of people who can understand and make sense out of it.

Now that the world’s all mobile + tablet, the new challenge is “user acquisition”. Growth hacking anyone?