Building Rapport – “How” you say it vs. “What” you say

A large portion of software product manager’s working life is spent working with cross-functional teams – whether it is trying to meet everyone’s expectations (or to be more exact aligning them), or communicating to them (since they often tend to speak using their own terminology) such that everyone is singing off the same song book. When you are new and have not established the rapport or the relationships with your shipmates, it is not “what” you say that tends to be important, but “how” you say it. Everyone is looking for “What is in it for them?” and “Why they should listen to you”. You have not earned your stripes yet. This holds true, no matter whether you are the new product manager or the new CEO.rapport

But once people get to know you and a good working relationship gets established, magic happens. Now, “what” you say becomes more important than “how” you say it. You could even drop every other word and speak (not that I recommend you do this) and still your team magically knows where you are coming from and what you are trying to say. Once the rapport has been built, people start believing in you and you can move a mountain.

So I don’t care what social networks come and go, what technologies make it easier to communicate, nothing comes even close to the traditional “human” face-to-face connection in building relationships. So what have you as a software product manager done lately to build or strengthen existing relationships at work? If you are new at your job, what have you done so that the magic happens that switches the conversation from “how you say it” to “what you say”? After all, it is all about human relationships, not about products. Relationships – internal and external – will outlast any product you will ever build.

Agree? Comments?

Image: Courtesy of presentationmagazine.com

Other articles you may like:

Customer Visits – Do’s and Don’ts

Don’t be an “I” specialist

B2B vs B2C Product Management -16 Differences

What should keep a product manager awake?

Should it be the state of product development, the next release, the next sprint? Should it be what keeps the company executives awake? Should it be the competitors? While some of these should indeed keep a product manager awake, the most important thing that should keep him/her awake should be what keeps customers awake. Customers have problems today that are real pain points. They are struggling to solve them using current means and are hoping that someone will solve them. They are willing to pay someone to solve these problems for them. This is what product managers should focus on and spend most of their energies. If you do this, everything else should follow. If you do not do this, then all of the other things tend to happen – your execs tend to stay awake, you start worrying about competitors, your sales start to shrink, you start worrying about hitting the numbers etc. So focus on the only thing that really matters – understand better what keeps your customers awake and solve them via your products – existing or new.

Thoughts? Please share them via comments.

Power of “Breaking it down” – 10 minutes and NOW

It has been months since my last blog post. Call it laziness, lethargy, procrastination, sudden lack of confidence in my writing skills – every one of these had something to do with it. I used to tell myself that I had to do it. But never did it.

Last night, I was teaching my 9 nine year old daughter Navya how to compute the area of shapes. I was teaching her how to break the shape into rectangles and squares, calculate the area of each and then add them up. Suddenly, it dawned on me as to how I could break down this wall of not blogging.

Image

It is simple – “10 minutes” and “Now”. I even have this written down on my monitor at work. When something feels too big and I have trouble getting started, I try breaking it down into steps each of which would take 10 minutes. And then I start doing them NOW. Believe it or not, it has been working and a proof point is this blog post. I just opened WordPress and started writing.

Try it for yourself. Whether you are a software product manager procrastinating on starting a requirements doc for a complex feature or you are a painter wanting to start a painting, break it down into “10 minute” chunks and start on it “Now”.

10 minutes get over fast and before you realize you are 30 minutes into it. The sense of accomplishment suddenly carries you forward. Agile development methodology is built on this core principle of breaking things down, building fast and shipping often.

Do you agree? Thoughts, comments?

Image: Courtesy of digitalminimalism.com

Agile vs. Waterfall – what is the big deal?

I have been working in companies the last 5 years where we have followed the agile methodology in product development. Shorter sprints, faster releases as opposed to month long development cycles that were common in waterfall.

Here is a guest blog post written by Mike Cudemo of Sparta Systems that explains the differences between Agile and Waterfall product development methodologies in a very simple way. He also explains the benefits of doing agile as a way of increasing the success rate of IT projects.

Seeing is believing.  Agile methodologies are not perfect, but they are three times more successful than traditional waterfall methodologies (source: Standish Group).  Agile methodologies allow end users and stakeholders to visualize their requirements faster and catch errors earlier in the development process.

A waterfall process can be likened to building a house.  An architect translates your requirements into blueprints which only an architect can visualize.  Your first glimpse into reality occurs after the foundation is poured and the walls are erected.   While things can be changed, it is more expensive to change.  Most people struggle to catch problems until the drywall is up and the ductwork and plumbing are in place.  Again, you can make changes if there are issues, however, now it is even more expensive to address.  The waterfall process attempts to “freeze the requirements” after the blueprints are designed.   As you can imagine, this is not reality.  The later you catch a requirements problem (e.g. I want a larger master bedroom closet), the more expensive it is to fix.  In some cases, it is impossible to fix.  You can have the closet, but little Timmy needs to sleep on the roof!

The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time.   It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements.  The Agile Method attempts to build the house by first creating a visual 3D representation of the outside of the house.  This is how it is going to look when you come home from a long day at work.  After the outside look and feel is developed, you attempt to construct the house one to two rooms at a time.   The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases.   Essentially, the Agile Method is a series of smaller contained waterfalls.  End users and business stakeholders get to see and experience the system as it unfolds.  Course corrections become more apparent and easier to navigate.

Waterfall processes attempt to minimize and control change.  Agile processes accept the inevitable need to accommodate learning about the real requirements.  End users think in broad strokes; however, we all know the devil truly lies in the details.   Skilled Agile development teams have a clear methodology to guide the process most effectively.  They will select the plot and then develop the look and feel of the outside of the house. Next, they will focus on the 1st floor, and then move to the second floor.  The finished basement will be last, because as we all know, we’ve run out of money by that time.

We find ourselves in the worst economy since the Great Depression.  Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments.  CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.

Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time.   It is better, but far from perfect.  It is clear, that Agile methodologies are at least 3x more likely to succeed.

Agile methodologies are iterative. Understanding is paramount to containing change.  Systems unfold one functional area and set of screens at a time.  An Agile Methodology will not fix a bad project vision, an impossible task, or a lack of skilled personnel.  Properly applied, an Agile approach will catch the poor vision, unattainable goals, or lack of resources early.  IT and application departments must learn that cancelling a project early is actually a win.   Broken processes should be fixed first before they become institutionalized with software or a system.

Companies that employ Agile methodologies and cancel unattainable projects early will thrive.  Their IT success rates will exceed 85%.  Most importantly, they will have more working capital to drive growth, innovate, and increase productivity.

About Mike Cudemo

Mike Cudemo runs the Customer Success Program at Sparta Systems.  The program accelerates knowledge transfer of best practices to our customers to enhance overall business performance.  Mike spent over 12 years integrating manufacturing operations with ERP and value chain systems at Fortune 100 clients, utilizing his expertise in value chain, quality, manufacturing execution and process automation systems. Trained as a systems engineer to analyze and simplify computer systems, Mike has spent a career helping clients understand their core business drivers, simplify the underlying processes, and automate the repetitive, non-value-added tasks which introduce defects and waste.

Importance of sprint demos

In an agile development process, you typically launch new features into production every 2-3 weeks. Before launch, it is important to ensure that all stakeholders get to know about the new features to be released. It is especially important for Customer Support, Training, Translators, Sales etc. to get to know these new features before customers get their hands on them. I have found the best way to do this is via a sprint demo. When I have organized these demos, here are three guidelines I have followed:

  1. All key stakeholders have been invited – marketing, sales, product, customer support, qa, …..
  2. The demo is held a couple of days before the release – stakeholders should have some time to react to the new features and also engineering – in case there are small changes that need to be made (textual changes or other very minor changes).
  3. The demo is done by engineering. This is very key for me. Engineers toil hard to get everything done and it is their work that is being shown in the demo. Given this, they are the best ones to show case what they have built. It also ensures that everything to be released is completed before these demoes.

What are your experiences? How do you do your sprint demos?

 

Understanding Constraints

In the past, I have written what a new software product manager should plan do in the first 30 days on a new job to be successful. If you are planning to start on the right foot at a new job, a key thing you need to understand is constraints. Especially in a startup, during early days when things are move lightening fast, shortcuts are the norm because of constraints. There is not enough money, people and most importantly time. You are trying to put your MVP (minimum viable product) out there, get early success to build upon that there are not enough hours in the day to do things better than you are doing now. 

So if you are a new product manager who walks into such an environment, the last thing you want to do is to criticize the way things are. Instead, spend the time to understand the reasons why things are the way they are. 9 times out of 10, the folks that have been there are not stupid to have done what they have done. The team will be very appreciative if someone takes the time to appreciate what they have done under the constraints they had. I am not suggesting that you be disingenuous and praise something when everyone around you knows it is a pile of shiitake. You have been hired for a reason. If you are hired as a VP of Product, it is probably because things have not been rosy and the company needs a direction. But before you start to rock the cart, first find the reason for the current madness.

Another occasion where understanding constraints becomes valuable is when you are making a business case for something. Sell the idea first (before you ask for resources), make sure there is buy-in and then outline the constraints that will need to be resolved if the idea needs to succeed. This could be asking for more people or funding.

Thoughts? Do you agree? What can you share from your experiences?

Image: Courtesy of scmep.org

3 mistakes to avoid in a Product Manager Resume

I have been reviewing tens of resumes lately as I have been looking to hire a product manager in my group at Care.com. Here are some patterns that I have noticed that makes me to quickly move on to the next resume:

  1. Buzzwords: When I read “Builds and manages relationship with customers to smooth transition from legacy, fragmented business processes and systems to streamlined global product development processes enabled by enterprise technology implementation that improve efficiency of new product delivery and sustaining engineering“, I have no idea what you are talking about and I move on very quickly to the next resume.
  2. No quantitative metrics: If I see no metrics or results achieved based on what you have done, I get no sense of whether your efforts were successful or not. Instead of saying “Launched a customer visit program for direct reports”, add more meat and metrics. Tell me what happened as a result. Instead, it is more useful to read something along the lines of “Developed an on-site customer visit program for direct reports that resulted in 200 visits/year. Improved understanding of customer product design needs resulted in launch of 5 new products in 2 years for the machine design and consumer design vertical segments.” It gives me context and also a better understanding of your accomplishments. However, never make things up, hiring managers will be able to sniff things out very easily. Trust me, I have seen candidates lie on their resume and it has come out within 5 minutes into the interview.
  3. No white space: Your resume is so full of text with minimal spacing, I as a reader have trouble focusing on something in your resume. It becomes a lot harder to read your resume. Presentation matters, readability matters. You want to stand out, make it easier for the hiring manager to read. Ask yourself this question – “Does my resume highlight my key achievements that will make the hiring manager want to pick up the phone and call me?” You do not have to put in everything you have ever done in your resume, what you want are your key achievements. The nitty gritty details can come in during the interview (if you think it is relevant to mention them). A good friend of mine, who has been a VP of marketing at many companies gave me a good rule of thumb – “1 page of resume for every decade of your experience”.

Thoughts? Comments? What are your experiences as a hiring manager?

Related articles:

  1. 10 job hunting tips for a product manager
  2. 8 traits of good managers
  3. 7 tips to survive a layoff

Customer Visits – Do’s and Don’ts

I attended the Product Camp Boston over the weekend and shared what I have learnt doing over 300 Customer Visits in 10 countries (US, Canada, Japan, UK, Germany, Netherlands, India, China, South Korea, Taiwan).

Customer visits can be the best qualitative method to learn the most about your customers/prospects – stuff you will not learn from surveying them. But this is only if you do them right. Based on experience doing 300 of them in 10 different countries, I would like to share what has worked and what has not.

Here are the slides I used.

I am looking to hire a Product Manager

I am looking to hire a Product Manager who has minimum 4 years of experience doing software product management (mostly consumer) to join my team doing product management for International products at Care.com. Details below. You MUST have 4+ years of experience to be considered. If you or anyone you know is interested, please send me your resume to gshenoy (at} care [d o t) com. 

The international group is small (total of 7), follows an agile development process and is very fast paced. We launched in the UK last month and will be launching in other countries very soon.

Product Manager based in Waltham, MA

Care.com is seeking a highly motivated individual to join its International Product Management team in the position of Product Manager. The individual will be responsible for defining, prioritizing, and overseeing the implementation of features and functionality of Care.com‘s international websites. The ideal candidate must have previous experience developing product requirements for an online, consumer service. In addition, the candidate must be able to effectively manage cross-functional teams of stakeholders throughout the organization.

Specific Duties/Responsibilities:

  • Ownership of product requirements for Care.com’s online product offerings for international markets. This includes the requirements gathering process, requirements documentation, and the ongoing maintenance of requirements as the business context evolves.
  • Working directly with stakeholders throughout the company to ensure that a successful product is delivered.
  • Working with business owners to understand and document the product requirements.
  • Working with engineers to communicate product requirements, make trade-offs, and oversee the product implementation and testing process.
  • Working with marketing to understand marketing plans and strategy and ensure the site and reporting platform support those plans.
  • Working with the member care team to ensure that product support concerns are addressed in the product requirements.
  • Working with the finance team to ensure that any revenue generated from the product is accounted for correctly.
  • Driving cross-functional teams to deliver a product which is on-time and in compliance with the product requirements.
  • Assist Director of Product Management in creation of product roadmap for international products.

Skills/Experience Requirements:

  • 4+ years of product management experience REQUIRED.
  • Experience working for a company/organization that develops and runs an online service, preferably a consumer-oriented service.
  • Experience working directly with customers in doing market research and usability testing.
  • Experience writing product requirements documents and functional requirements documents. This includes experience developing wireframes using tools such as Balsamiq or other similar tools.
  • An understanding of Information Architecture and a passion for defining a highly-usable online experience.
  • Demonstrated ability to manage cross-functional teams, solve complex problems, and produce high-quality results.
  • Knowledge of and experience with reporting requirements of an online product.
  • Experience working in an agile development environment.
  • Ability to roll up the sleeves and work in a fast-paced, start-up environment.
  • Excellent oral and written communication skills.
  • Ability to work independently and in a team environment.
  • Willing to travel internationally as required to meet with customers (travel expected to be less than 5%)

Education/Other Pre-Requisites:

  • BA/BS degree in engineering or related field.
  • Knowledge of German, French or any other languages considered a plus.

 

Market Sizing – Quick and Dirty Techniques

This post is a guest blog post by Ilya Mirman, former VP of Marketing at VMTurbo, CilkArts (acquired by Intel), Interactive SuperComputing (acquired by Microsoft) and SolidWorks Corporation. Ilya is currently an advisor to many startups in the Boston area.

I was 9 years old when my father taught me how to estimate the height of a building using my thumb and simple geometry.  As engineers we are taught estimating techniques – in school, and by colleagues and mentors.  Quick-and-dirty assessments are indispensable as we engineer new products, and they’re just as critical for product managers exploring new markets and products.

Being able to quickly size a market is quite handy at several points in a product’s life cycle.  I am not talking about achieving the third decimal point of accuracy at a 95% confidence level; rather, I am talking about being able to know within, say, a factor of two or four what the opportunity might be.  Here’s just a few of the situations I’ve seen where roughly sizing an opportunity helped lead to a better decision:

  • What is the market opportunity for Product X?  This is useful not just for go/no-go decisions, but also for what might be the right way to bring a product to market.  For example, a line extension that can appeal to 15% of your existing user base might be a very attractive new add-on for your company to introduce; though it may not, for example, warrant a spin-out or significant engineering diversion.
  • What is the right funding and development path for New Idea X?  A new idea may be worthwhile, regardless of whether the opportunity it represents is $5M, $50M, or $500M.  But it sure might be helpful to have a clue as to which it might be!  If it’s $5M, it might be an interesting lifestyle business; if it’s $50M, it might be an interesting company for a couple angel investors to help get off the ground; whereas at $500M and up, it may be worthy of a venture capital investment and more aggressive development and go-to-market plans.
  • Which user persona to target for the first release of Product X?  Often, a product might appeal to a couple different user types.  But rather than engineering the “gray sneaker” (when half the users actually want black, and the other half want white), it may be better to figure out which segment represents a better opportunity, and really optimize the product for them.

There’s no one “right” way to do market sizing, and in fact it’s often useful to triangulate using multiple approaches, to increase your confidence that you’re in the ballpark.  Here’s a couple examples.

Top-Down: The Filter Approach

The approach here is to identify a key metric that’s driving the opportunity, and the key assumptions / reduction filters to zero in on your addressable market. One of my start-ups was Interactive Supercomputing (a venture-backed MIT spin-off acquired by Microsoft).  Our software connected engineering desktop applications – such as MATLAB® or Python – and parallel servers, to solve large and complex numerical problems that can’t be solved with a desktop computer.

The market for high performance computers (also known as “HPC servers,” or “parallel servers”) was large and reasonably well-known – hundreds of thousands of servers sold annually.  There is a broad set of diverse applications and usage scenarios for HPCs, so the big question for us was, how many of them could benefit from our software?  Here are the three primary filters we identified:

  1. Fraction of servers to run custom applications: The software running on these servers falls into 2 categories: it is either an existing software application; OR it is a newly developed application, currently being prototyped on a desktop tool.  Our software was suited for the latter scenario (enabling a much quicker path going from desktop prototype to deployment on a server).  Our research suggested that roughly half the servers purchased every year were for running existing apps, and half were for custom apps.  This 50% was therefore a constant filter in our model.
  2. Desktop Language Support:  The first filter helps us identify the servers running new custom apps.  But that would be an overestimate, because our software was not able to help every one of the custom app developers.  Turns out that a second important filter is: which desktop tool or language is used to prototype the application.  Our initial product supported MATLAB, which according to our research was used to prototype ~25% of the custom HPC apps.  Over the following 3 years, we planned on introducing support for Python and R, expanding the addressable market to 50% of the custom HPC apps.
  3. Product fit: The third and final filter was product fit.  Our software did not support all domains and applications equally well – for example, we were great for signal processing, but not genetic algorithms.  We broke down the numerical methods into about 10 domains, identified our sweet spots, guesstimated which ones we’ll strengthen over time, and felt that a reasonable model might be to grow this filter from 25% to 40% over 4 years.

Here’s the resulting model – we start from the universe of servers sold in the HPC space, and zero in on the footprint of ones we can address well.  Because two of the filters grow over time, as does the absolute number of servers shipped, the market grows rapidly:
(Note: I’m glossing over a couple details here, for clarity.  First is the connection between number of servers and the dollars spent.  And second, the fact that in addition to new servers modeled here, there is an installed base which is approximately 3 times larger, though less of them are available for new custom applications, and are typically not being sold to by the channel we were betting on.)

Bottom-Up Estimate

In the bottom-up approach, rather than starting with some total and filtering it to the relevant fraction, we do a bit of the opposite: identify the segments, to build up the total market opportunity.
At my next start-up Cilk Arts (a venture-backed MIT spin-off acquired by Intel), our mission was to provide the easiest, quickest, and most reliable way to optimize application performance on multicore processors.  Our software consisted of developer tools, and a runtime system.  We had hundreds of conversations with a broad set of organizations looking to make their applications run faster on the new generation of microprocessors from Intel and AMD.  We saw a large variety in terms of product fit, how many applications they develop, size of their user base, and what they may spend.

So to size the market, we identified the key segments, and estimated the key variables:

  • Number of firms in each segment: through web searches and other data we actually compiled a list of many of these;
  • Number of apps developed per year;
  • Product fit:  Fraction of their apps we could accelerate (we had better performance in some sectors, and less of a fit for others);
  • Estimate of value for each app based on conversations with hundreds of prospects.


My sense is that it was less important to know whether $480M was “right” and more important to quickly figure out that it was neither a billion-dollar opportunity, nor merely a $100M market (where the leader might garner a ~20% share).

Conclusion

Because there is no one source of info is that reliable or complete, it’s better to use multiple approaches to zero in on a good estimate.  Try to identify metrics that correlate with usage or size of the problem – possible sources of data include government databases, relevant publications’ reader studies, commercial databases, competitors.

What approaches have YOU used to estimate market opportunity?  We’d love to hear from you.

Product Manager’s friend: Momentum

What a product manager needs to succeed is momentum. Momentum in product development, in product sales, in customer adoption, …. – you name it. Lack of momentum is akin to death. If your company is not willing to make necessary investments in your product, it will die. If enough engineering resources are not dedicated to your product, it will die. If there is not enough marketing muscle put behind your product to create awareness and interest, it will likely fail. So what can you as a software product manager do, to get this “momentum”?

  1. Earn customer capital: If you can show that you talked to real customers who are likely to buy your product as opposed to holding on to internal opinions, you stand a chance to gain momentum. Even if you don’t talk to customers, but instead have data that proves user behavior (for example web analytics data), you are likely to gain momentum.
  2. Political capital: If you can make a business case on why the company cannot ignore the opportunity you have identified based on the “customer capital” you have earned, you are likely to gain momentum. If you can get buy-ins from individual stakeholders and get their backing, you are likely to gain momentum.
  3. Early market success: If you can build a minimum viable product, launch it into the market and get early market success, you will likely win over the last standing doubters and build momentum.

If all you have are your opinions, you will lose to the HiPPO (Highest Paid Person’s opinion). Instead if you have data to back up what you are saying, you are likely to gain momentum that will make you successful.

And in spite of all this, if you don’t, it may be time for you to move on. Trust me, I have been in this situation, where no matter how much data I brought in to prove my case, it fell on deaf ears and the organization was more concerned addressing what appeared as the “next big deal” that the product which was bringing in the bacon was left to languish. All you can do then, is know that you put the best foot forward and hope for the best.

What do you think? Do you agree?

Focus is about saying “NO”

It has been a while since I have been in blogging and a lot has happened in the world during that timeframe. My idol Steve Jobs has passed, iPhone 4S is out, Gaddafi is dead, Greece has been in turmoil sending the financial markets on a dizzing roller coaster and the list could go on.

After Steve Jobs death, I have gone through many of his well known presentations of introducing the iPhone and the iPad and many other videos available on Youtube. There have been two videos that are my favorites – one of them is where he speaks about “Focus is about saying NO”. 3 minutes of your life spent watching it would be worthwhile. Watch it once, watch it twice, watch it until you keep repeating “Focus is about saying NO”.

As software product managers, every one of us is faced with the hundreds of things we could do and what others in the company want to do. But what will allow us to succeed is not by building something that does a half assed job for everyone (you will hear this being argued for under the name of flexibility) but by focusing on building something that does a kick ass job doing a few things very well. To do this however, you need organizational support – it needs to come all the way from the top – the CEO.

Thoughts? Do you agree? What have your experiences been?

Where should product management report to?

In an organization, where should product management report to? Sales? Marketing? Engineering? CEO? Customer Support? All of this is possible but where can it be the most effective?

Before we answer this question, let us make sure we are aligned on the role of a product manager.

In my opinion, the best spot for product management is to have it report directly to the CEO. Product is one of the most important functions in an organization because getting the right product/market fit is what brings in the revenues. So I would argue that this needs to be have a direct line to the CEO so that it is not only looked upon as a strategic function but also that it is held accountable for the company results.

Is there a second best place for product management? Every successful organization that I have worked for (B2B or B2C) has had product management report to Marketing. Marketing naturally is an external facing function that is responsible for identifying the target market, figuring out the product positioning and figuring out what will make prospects buy. There is a slight danger here of product management becoming “marketing” driven than “market” driven, but I think with the right leadership this can be avoided.

The slides shown below are my opinions on why it should not report into sales or engineering or customer support.

Would love to hear your thoughts on this via comments. Do you agree?

Product Management Career Tip – Don’t be an “I” or “they” specialist

On Friday, I had to complete my self evaluation of my Q2 performance review. As I was reviewing myself, I noticed that I had to continously mention how “I” got this and that done. Too many “I’s” were making me uncomfortable that I had to pause and think about it, but was soon to realize that it was appropriate because this was my self evaluation – a self reflection on my performance/accomplishments/mistakes and not the group performance.

However, in the normal working life as a software product manager, there is typically no “I”, there is no “they”, it is always “We”. I get quite irritated when I meet such “I” specialists for whom everything is “I said this”, “I did this”. As a software product manager, there is very little that you can do which is not a group effort. Whether it

is working with your development team, your marketing team or your finance team or your product management team, your accomplishments are primarily achieved by working with others. Hence, it is typically “We” did this or “We” should do this or “I” recommend that “we” do this.

Then there are the “they” specialists – folks who refer to their employers as “they”. For example, “I” recommended this, but “they” don’t want to do it. You are far better off pitching this as – “I” am recommending this because “we” can get to X,Y and Z. You come across as a true team player in your internal and external conversations. If you do this well and if you had a primary lead on some of these accomplishments, the right people should notice the leadership role you had to play. That recognition is far better than having to promote oneselves at every possible opportunity.

This is especially important when it comes to job interviews. You want to come across as a team player and “we” is the way to go. If all you do is become an “I” specialist or “they” specialist, it does not come across well. Of course, there are instances where you have to talk about what you have accomplished, but you will still be better off if you refer to some of these with a “We”. “They” when referring to an employer is best avoided.

Agree? Let me know.

Humans crave for predictability, are you providing it?

Last week, Gazelle moved its office from Allston to downtown Boston. No move is easy – new desk, new neighborhood, new commute, everything to get adapted to. My commute to the new office is now 1 hour 45 minutes each way. I have to drive to the train station for 20 minutes, take the train that takes an hour and then walk to the office. Sounds like an awful lot and it is – 15% of my day is now spend commuting. My previous commute was anywhere from 50 minutes to 1 hour 45 minutes. But I enjoy my new commute a whole lot more even though it takes a whole lot longer. For a very simple reason – predictability! I now know that as long as I get to the train station on time, my commute time is going to be 1 hour 45 minutes (barring any train breakdowns of course). Of this time, the 1 hour of the time on the train is actually spent relaxing – whether it is typing this blog post or taking a nap or reading. I enjoy the 10 minute walk from South Station to the office – free exercise. It is 2 hours that I get for myself everyday. Humans crave predictability and are likely to give up things for it.

The same applies for products. Some choose to

  1. Work in larger companies instead of startups because of the predictable hours and also job safety.
  2. Become full time employees than being consultants because of the predictable income.
  3. Buy products from established vendors than fledging startups because it is a safer bet.
  4. Have caps on pay-as-you-go software packages so that they can have predictable expenses for budgetary purposes.
  5. Buy software packages that have more features than they want now, because it is a safer bet to make now.
  6. Buy extended product warranties because it adds predictability that if anything goes wrong during this time, they do not have to spend money.
  7. Pay bills on the same day every month because it allows one to have a predictable cash flow.

In most cases, products are expected to have predictable outputs to given inputs. So, in our lives as software product managers, adding predictability to our customer’s business or personal lives could be a dimension used to enhance our products. And once you do, make sure that this is pitched to your customers – because they may not tell you that they are looking for more predictability, but I will bet you that unknowingly they do.

Makes sense? Let me know.

When does a startup stop being one?

When does a startup stop being one? Is it when:

  • It gets funded – no, can’t be because vast majority of them get seed funding.
  • It gets customers – no, that can’t be it either
  • It gets revenues – no, because customers could be paying for the service
  • It becomes profitable – no, because even profitable companies are sometimes called startups.
So it was something that had been bothering me for a while. I have asked others but never got a satisfactory answer. Then couple of weeks back I attended the simulcast of Lean Startup held in San Francisco – beamed to the Microsoft offices in Cambridge. There I heard the definition of a startup from Steve Blank which makes a whole lot of sense – “Startup is a temporary organization designed to search for a scalable and repeatable business model“. That to me gives a very easy criteria to determine when a startup stops being one.
Thoughts? Kindly share your thoughts via comments.
Image: Courtesy of freeclipartnow.com

B2C vs. B2B product management – 16 differences

Most of my product management career has been spent doing B2B product management. For the last year and a half, I have switched over to B2C product management in my current role as Director of Product Management at Gazelle. Last 12 months has been a lot of fun learning a whole lot of new things in the consumer world. Given this learning, I have been able to create a long list of things that matter a whole lot more doing B2C product management that may not be as important doing B2B product management. Here we go:
  1. It is a millions game - Victory is declared when you have million+ customers, not hundreds or thousands (if your goal is to become the “brand” in the space you are in) unless you are in a niche market.
  2. There is one buyer most of the time – no technical buyer, no economical buyer, no user. The consumer is coming to your website with intention to buy something for themselves with their money. (exceptions do exist – for example, if I am buying something for my wife or kids or my mom – though this is not the mainstream use case).
  3. Short sales cycles - Ideally you want every customer to buy from you on your first visit (never happens, but the goal is to get as many to do this). There are no RFPs, no demos, no data sheets, no whitepapers, no lunches with prospects to convince them to buy. Your website is the demo – if they don’t like or understand something, they will leave and may never come back.
  4. Show me the money  – It is harder to monetize consumer products. A lot of apps, services are available for free, and consumers are used to getting products and services for free online. Consider a limited-feature free product or limited-time free trial offer, setting the stage and expectations that they will need to pay. Make sure that the value proposition is crystal clear to the customer.  Remember, they are spending their hard earned money and not their employer’s.
  5. Short attention span – KISS (Keep it simple stupid) principle applies so much in B2C. Use middle-school reading level language on your site – short, simple, easy to digest. None of the gobbledygook you can get away in the B2B world with (the reliable, scalable, innovative, high performance, architecture marketing BS) works.
  6. Details matter even more – Given the short attention span and the high propensity to go elsewhere (one mouse click away), everything from page load times count. If your page takes long to load (read that as more than 2 sec), chances of your prospect leaving go up exponentially, unless you are an established brand (read Amazon or Google).
  7. Product experience rules - Site usability matters a whole lot. There is no consulting, no professional services in the B2C world. Either the customer gets it the first time or by quickly looking through your FAQs or they just leave.  If your product is not easy to use, expect it to be returned (or if it’s a website, abandoned). Consumers rarely RTFM.
  8. Customer experience rules – You need to deliver a “crazy awesome” customer experience to every customer.  Over and above the product experience, you need to deliver an awesome experience at every touch point – whether it is customer care, online content, surveys, newsletters – you need to aspire to beat your customer’s ever rising expectations. Why? See #9.
  9. Social proof is mandatory - Consumers look for social proof – who else is using it, what do other think about it? Is this site real and trustworthy? Again, remember, they are spending their money and not their employer’s. And by social proof, I don’t just mean canned testimonials (which by the way lot of buyers do not trust), but instead they expect to read both positive and negative reviews about your service on the web, Facebook, Twitter etc. If you deliver an excellent experience, they will tell others. And if you deliver an awful experience, they will tell even more people and you will not even know. However, they do not expect you to deliver an awesome experience to everyone – some customers can just not be pleased and no company is perfect – you are bound to screw up at least in some cases. So if all they see are positive reviews, it could be a cause for concern (trustworthy?). So, instrumenting your product to allow your customers to easily share their experiences (good and bad) is important.
  10. Building brand equity matters – You need to appeal to the masses right from the word “go”, but it will take time. There is no fast way to get there. But once you have built and earned good brand equity, you will retain the consumer mindshare for a long time. For example, when it comes to buying books, do you think of Amazon or Borders? When you think about mp3 player – do you think of ipod or zune? When you think about search, do you think Google or Microsoft? When you think social media, do you think Facebook or Orkut? It took a lot of work for all these companies to get to where they are now. Why? Read #1 again.
  11. Web analytics – In the B2C world, you live and breathe “web analytics” – unique visitors, bounce rates, traffic sources, conversion rates, conversion lifts, funnels etc. become part of your everyday terminology. It is all about getting more customer traffic to your website and getting them to buy or do whatever that helps you make money. If you are running an eCommerce site, you want to make sure they find the thing they want and then buy it from you.
  12. Test, test, test – Getting ready for continuous A/B testing and multi-variate testing becomes part of your DNA. Consumers are fickle, they change their mind all the time. Hence, no matter how many usability tests you have done before you release changes to your site, it can never guarantee success. You need a lot of data points to declare a winner. The only way to find out is to release changes to production and then conduct A/B or multi-variate testing before you declare a winner. Be prepared for surprises, because what you think will win could turn out to be a sore loser.
  13. SEO, SEO, SEO – every page you create on your website needs to be SEO (search engine optimization) friendly. Why? Your highly qualified prospective customers will find you primarily via two mechanisms – 1) search engines when they are about to buy what you are trying to sell or 2) by word of mouth. So as a B2C product manager, you need to have a decent knowledge of how SEO works.
  14. Keep them loyal – As I have mentioned before, word of mouth is huge in the consumer world. Because it is not one person telling another, it is one person telling 10 of his/her family or friends. Consumers love loyalty programs – it is your way of thanking them and keep coming back. I still fly American Airlines because that is where I have the most miles. (I hate their customer experience, but I still remain loyal because of the miles).
  15. Respect their privacy – Ask only for personal information that is absolutely needed. If sensitive personal information is asked, explain how you would use it. If a consumer opts out of receiving marketing material from you, respect that.  Do not require them to “register” with your site to use your product/service unless required. Allow for “guest checkout”.
  16. Stay in touch – via newsletters, Facebook. Get them to “like” your FB page – use your page for periodic product updates, contests, relevant news, etc. Remarket to them with relevant content, coupons etc. But never, ever spam your customers.
Do you agree? What else are the differences between B2C and B2B product management that you have come across? Kindly share your thoughts via comments.

My recent Product demo experience – 3 key learnings

In the past few weeks, I had the opportunity to sit through three product demos that were all done using web conference (Goto Meeting and WebEx). Two of these demos went very well, we understood everything we wanted to know and we figured out whether the products will meet our business needs. More on that later.

The third one was an outright disaster. This particular  demo was in an area that not many of us knew enough about and we were looking to educate ourselves with not only on the product but also get a better understanding of the underlying methodology. When the demo was set up, we had clearly communicated to the vendor (at least we thought we had) on what we were looking to get. We had also indicated that time was tight and that we probably had 45 minutes max. To make the whole situation tricky, there was the software vendor, a potential professional services partner and an internal consultant who was introducing us to the software vendor.

Here is how the demo went (remember the 45 minutes equates to about 20 min of demo time if you account for the time needed to answer questions during the demo):

  1. 15 minutes were spent on the corporate slides – here is who we are, when we were founded, we do blah blah blah (nothing I remember right now), here is how much profits we made last year, here are the complex equations that are underpinnings of the technology (I am not joking, there were equations on slides), here are the Fortune 500 clients that use us etc.
  2. Another 15 minutes of the admin console where everything can be looked at etc.
Here is what transpired amongst the audience which btw had all the relevant stakeholders:
  1. In the first 2 minutes of the corporate slides, most of those in audience lost interest and were busy checking their emails
  2. By the time, 15 minutes were up, we had still not learnt anything that we came to learn about. People were feeling cheated – why are we wasting time on this?
  3. What followed was tech focused, nothing addressed the business problems we were looking to solve.
  4. Nothing was professional about the demo, everything looked like a hodge podge.
At the end of 45 minutes, we did not get much out of it. Half the folks had to bail because they had other meetings to go to.
Now allow me to compare and contrast the above experience to the two successful demos:
  1. These two vendors did discovery work to find out the business problems we were facing and they did this directly with me – before the demo. To their advantage, there were no middlemen.
  2. During the demo, they focused on our business problems and not themselves (not one word on who they are, how big they are etc.) until they had completely addressed how their solutions could solve our business problems.
  3. Everything was done in the allotted time. They followed up with emails to check if we had any outstanding questions and enquiring about the next steps.
So what are the key learnings from all of this for those folks putting together product demos. Here are my recommendations:
  1. Do the discovery call before the demo: If you are the one doing the demo, try your best to engage directly with the customer for a discovery call. Avoid leaving this to a third party unless these folks can educate you well on the customer’s business problems. Find out the business issues faced by the customer, how they are solving the problem today, what solutions they are using etc., timeframe they are looking to solve the problem and if they have a budget. Budget and timeframe to purchase are very important – if there is no budget, it is a lot harder to sell.
  2. Business problems first: Your prospective customers don’t care who you are, how big you are or how great you are, unless you can solve their business problems. The only reason they are engaging with you is to find out if you can help them. Satiate that need first, nothing else. Everything else can wait. Stuff for the economical buyer (financial viability, your revenues etc.) or for the technical buyer (technology underpinnings etc.) can come later – not in the first demo. Selectively disclose stuff – peel the onion one layer at a time – don’t bury the customer with information, keep it simple.
  3. Respect the customer’s time: Find out ahead of time how much time you have and who will be in attendance. If the time is insufficient for you to do the demo effectively, ask for more time. Explain why it would be beneficial to allot more time – start becoming an advisor to the customer. Once you know your constraints, honor them. Make sure you hit the salient points customer is looking for during the allotted time. If you do this right, two things will happen – you will get more time right there and then or a follow up demo will be set up to take this further. If either of this happens, you now have an engaged prospect and you are making progress towards closing a sale.

You can choose to avoid doing the homework to your own peril or spend the time during discovery to start building effective relationships with your prospects.

Thoughts? Do you agree?

If you read this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)

Image: Courtesy of carecleaningandprotectionexperts.com

Prioritize based on frequency, not size ….

When I have done customer interviews to better understand customer pain points and ways to enhance the product, often times I have been asked one of two questions:

  1. Are you really interested in solving this or listening to my problem? I only have 2 licenses of your software. Don’t you only listen to customers who have 50 licenses or more?
  2. But this is a simple issue, will this ever make it into your list of things to improve on?

I remember giving the same answer each time for question 1) – my job as a product manager is not to worry about how many licenses (“size”) you have, but to understand your pain point and then extrapolate to see how many other customers will benefit from solving the problem (“frequency”). Innovative ideas typically come from one individual (think about all the great inventors – many of them invented things in their basements individually) and not from organizations. So before you ignore your small customers, think twice. Instead worry more about the “frequency” of the issue.

The second concern has some validity. Companies under the false pretext of being innovative are looking for problems that are big news – the one that will make a splash. Agreed!  Product managers should always look for differentiated ways to solve “common” problems to stay ahead of the competition. But this should not be at the cost of ignoring simple issues with your current product. Here is a simple formula I have used to prioritize all of the issues.

Determine:

  1. How many times a typical user encounters the said issue? (Once a day? many times a day? once a week, once a month, once a year etc.) = A
  2. How much time in minutes do they waste each time they encounter this issue to find a workaround? = B
  3. How many users will encounter the same issue? = C

Importance of the issue (priority) = A x B x C

For example, if the user encounters an issue with every 3rd mouse click (because of the delay the software responds to the click) and if a large number of users encounter it, it will be amplified a whole lot even if the delay is only a few milli seconds. Compare that to an issue which occurs once a year for a very few users. It maybe something you could easily de-prioritize because it could very well be a niche problem.

Don’t get me wrong, lot of emotions do get involved in whose issues get fixed – one with executive mandate, one from a vociferous customer, one for the customer that will make a huge purchase etc. But as a product manager having the above data will help you justify the prioritization you are making and then if someone wants to override your decision for valid/invalid reasons, that is perfectly fine. At least you should be able to sleep in peace that you did your homework.

Thoughts? Do you agree? How do you do prioritization?

If you read this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)

Image: Courtesy of fiscalgeek.com

5 things I learned about Software Product Management in India

I am currently enjoying my week long vacation in my hometown of Ernakulam after a week of software product management seminars and workshops in Bangalore and Hyderabad. As a bonus, my host Pinkesh Shah, CEO of Adaptive Marketing and I were invited to the Indian School of Business in Hyderabad by the students who were keen to learn more about product management.

So what did I actually observe and learn from the 125 product professionals I interacted with? What is the real state of software product management in India? What are the software product managers doing now and what are they looking for? Though I did not get to meet with software product managers from large MNC’s such as Google, eBay, IBM, Cisco etc. that have large operations in India, my numerous conversations with Pinkesh indicate that the picture there is not that different from what I learnt from the product managers I met with.

So here are the top 5 things I learnt about software product management in  India.

1) Current focus is on requirements management and software delivery: Software Product Managers in India currently are playing the role of requirements managers or product owners (in the world of Agile). They are responsible for defining the product functionality and working very closely with engineering teams co-located here in India to ensure the iterations/releases get delivered on time.

2) They manage products sold in the United States: The products they work on are primarily (if not all) for the US market. Hence, the amount of direct customer facing activities they take part in is very limited at this time. They do not seem to have many opportunities to travel to the US to meet with their customers. They understand this as a major pain point. In most of the cases, the Indian product managers (I got to speak with) do not have a product management counterpart in the US. Input for the product enhancements were coming directly from marketing, sales or the executive management, as opposed to someone who was spending time listening to the customers in a non-sales situation. This is very worrying because those of us who are experienced product managers know how frustrating listening to just sales to drive future product direction could be.

3) Titles are one too many - Just like in the US, there are too many titles for product managers in India. Technical product manager, product owner, product manager, product professional, the list goes on.

4) Engineering talent is itching to find new career opportunities: Folks who have spend a lot of time in engineering and project management are now starting to ask – what next? I heard this during my seminars and it is also a common question I get from the readers of this blog – how to transition into product management. Training demand and opportunities for vendors who provide training on software product management are bound to increase.

5) They are confident, fearless and hungry: What impressed me the most was the talent and the confidence of the software product managers in India. There are some that work on very successful products in the marketplace – for example, the product managers Mukesh Marodia and Ramesh at OpenText were working on a very successful portal product used by a number of Fortune 500 (apparently 1 out of 3 pages on the internet is powered by Open Text web cms). The product managers at Nokia were working on the different software components such as messaging and video capture used in all of the Nokia mobile phones. Then there was Chaithanya from Inmage Systems, the lone product manager in the company responsible for his company’s data recovery solution sold in the US. I could go on, but all in the all I was so impressed by the budding product management talent in India.

So what is the future? I am convinced that the talent in India has a bright future ahead. I am making a bold prediction here, not based on facts but based on the trend that I have been reading about. Given the size of the Indian market in terms of number of consumers and their total purchasing power, every company on this planet will be looking at building new software products for the Indian market. Software products that are not watered down versions of products build for the western markets and then adapted to the Indian market, but instead software products that are designed from the ground up in India for the Indian market. We already read about this trend in companies such as GE and automotive markets, but I am predicting that this trend will heat up in the next 5 years. When this happens, the current software product management talent in India would have matured enough to play a significant role. They will soon find themselves in an enviable position where they will no longer be concerned about lack of opportunities to meet with their end customers because they will be living right amongst them. These software product managers are hungry, smart and more importantly they are confident. I am so happy to have met these budding product managers and their future cannot be any brighter. Product Managers in the western world (including myself) take note, I treat the talent here in India as competition for sure.

If you enjoyed this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)

Follow

Get every new post delivered to your Inbox.

Join 232 other followers

%d bloggers like this: