Tag: product manager

Death by a thousand paper cuts ….

In my last post, I discussed the benefits of doing an on-site customer visit where you get to observe customers/prospects use your product or competitive products to get their job done. In my experience doing these visits, I often discover what I call “death by a thousand paper cuts” issues. These issues are essentially annoyances that your users have to put up with when using your product. By itself, each of these issues will sound trivial. If your users call you up to complain about any one of these issues or to propose a solution, you could easily laugh it off as trivial.

But when you are on-site observing these customers, you will notice that these trivial issues quickly add up to cause significant loss of productivity for your users, especially when your users have to encounter them each and every time they use your product. But these to me are the slam dunk features – they are so trivial and hence are usually very easy to fix, but when you fix them you will be able to significantly improve the user experience. Your customers will notice these small improvements because they will reap significant benefits especially if these issues were in the way of a frequently performed task.

I have had many instances where such simple fixes have generated the loudest applause from the audience where as the big feature we were so proud of was met with very muted applause (to our chagrin, if I may add). Have you experienced something similar?

Thoughts?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Five reasons why customer visits “rock”

I am a big fan of customer visits – ones where a software product manager visits customers on-site and observes them using your or competitor’s product. Now why do this? What are the benefits of doing this over talking to the same customer/prospect over the phone, while at a conference/trade show or doing a survey etc. Here are the 5 reasons why I find a customer visit trumps other market requirements gathering techniques:

1) Customers misstate their pain points: Yes, they do. But not because they want to mislead you. But because what customers tell you is often very different from what they do. For example, let us say you are on the phone and ask them to walk you through the different steps they do to complete a particular task. They will tell you what they can remember. When they articulate these steps they usually tend to remember the ideal way they do things or the way they are supposed to do things. But this is often not the way they end up doing things. There are always quirks, there are often painful detours which you will never get to know. These painful detours could be a gold mine for usability issues to solve such that the customer’s life becomes a lot easier when using your product. customervisit

2) They don’t want to look stupid: Usually customer phone calls have multiple representatives from the customer side and often folks with varying responsibilities and varying levels of expertise of your product. It is difficult for someone who is not as good as using your product admit that it is very difficult to do something. Here is a typical scenario:

Bill (a new user who is struggling with or learning your  product):  “You know I wish your product was easier to use when it comes to  doing <insert one of your product features here>. I use this every day and every time I use it, I either lose data or the performance is very slow.”

John (Mr. Power User who is also on the call):  “Oh Bill, that can be easily done. It is because you don’t know about feature X. I will show you how to do it after this call.”

Do you think Bill is going to tell you any more of his pain points? He shuts up from there on and all you get to hear would be from the Mr. Power User, mostly things that are useful for the power users. Don’t get me wrong. Mr. Power User could be the most passionate visionary you want to tap into or could be the most opinionated, smooth talking person who pretends he knows it all. You have to be understand which of these two you are dealing with. The above scenario is difficult to do over the phone, but easier to do when you are meeting them in person (because you can choose to meet in private with Bill or ask him to show you how he uses your product).

3) Surveys: Good data gathering tool when you are ready to do quantitative evaluations, but only to augment the qualitative data gathering you have done via customer visits. Again when responding to survey questions, customers will answer on how they think they are doing something vs. how they really do it. Surveys typically do not capture the real pain points customers experience. The customer also tend to propose solutions when responding to survey questions as opposed to explaining the real problem that needs to be solved. Survey responses by their very nature are monologues and are not a conversation.

4) Customers do not know what they do not know: Humans quickly get used to doing things in one way that it becomes second nature. Once you get used to something or you are too close to the problem – you lose the objectivity. By observing customers in their native habitat, you are able to observe all the inefficient things that they do by second nature. By observing these things and by solving them, you would provide solutions to problems that the customer did not even know he had. You get respected for your ability to look out for the customer.

5) You get to see the customer’s “native” habitat: Where does the customer spend his time when he is working? A nice cushy air conditioned office? Or a dump that is next to the manufacturing floor where it is noisy and dusty as hell? How computer savvy are they? On one of my customer visits, I visited a customer for whom Ctrl-C and Ctrl-V were major revelations. And he has been using the computer for a long time. It is very easy for us when sitting in our offices to assume that our customers are computer savvy. What are your typical customers like? Ones that wear suits to work? Or ones that are in shorts and flip-flops?  How often do they get interrupted when trying to use your product? All of this will help you build up the customer persona you are designing for and also understand where your product fits in the customer’s working life. None of this is possible to do via customer phone calls, surveys or even while meeting customers in your offices or trade shows.

Thoughts?

Ten job hunting tips for a product manager

I had mentioned in my last post that I would post tips from my experience looking for a job as a product manager – in fact I had to do this twice in the last 7 months. So here is what worked for me … Remember one thing – job hunting is nothing but a marketing and sales job of a single product – You !

1) Don’t respond to job postings unless you want your resume to end up in a pile.

2) Get your foot in the door: Instead, if you find a job in a company X that you want to apply for, use social networking sites such as LinkedIn (this is the only one I use) to see if you are connected to someone who works there or if one of your connections knows someone who works there – then get recommended. You are looking to get a foot in the door and get the first phone call. Candidates who have been recommended by internal sources will at least get the first phone call – it is up to you to take it from there. If you know someone at the company, it will also give you an inside scoop – what is the real story, how is it to work there, anything about your future boss you need to know about – his/her management style etc.

3) Call the hiring manager: If you are not connected to anyone, again use LinkedIn to see who the hiring manager could be – I look for titles such as VP of Product Strategy, VP of Marketing, VP of Product Management etc. If LinkedIn does not have it, look at the company’s website under the Team/Management section. Then call the company and ask for that person – if you do get the person on the line (tough because people are travelling or are in meetings), tell them who you are and why you are calling. If you get the standard response of apply for the job and send it to HR, be frank and tell them that you are trying to get your resume visible and ask if you can send the resume to him/her so that he/she can send it to the hiring manager. There is nothing wrong in asking, worst response you can get is a No. A lot of times this will work and it also shows your initiative and strong interest. Then email your resume within a day so that your name is still fresh in the other person’s mind. Followup with the person via email (no phone calls) after a week if you have not heard anything.

4) Email the hiring manager (long shot): If you do not get hold of the hiring manager over the phone, then try the long shot – you need to figure out if you can get his/her email address. How do you know if it is roberts@xyz.com or robert.smith@xyz.com or smithr@xyz.com – look at the bottom of the press releases at the company X’s website. The company’s contact for the press release typically puts his/her email address at the bottom – this will get you the syntax. Again, sending a cold email is a very long shot and may get you a response only if you are a very strong candidate. I will not follow up on such an email because you don’t want to spam the person.

5) Work your network – there is a great book of “Dig the well before you are thirsty” that is worth reading – basically don’t try to create the network just when you need it – keep your network alive, help others when they are in need and they will help you when you have a need.

6) Get involved in local product management associations – present at conferences on product management topics – you want to be seen as a subject matter expert – you need to do things (good things !) that will let you stand out in the crowd.

7) Always keep looking for a job – you never know what opportunities come along your way – but you don’t want to be switching too often either – pick a job that broadens your experience, stay there for a while, succeed and then think about making a career move.

8. Research, research, research – Get to know about company X as much as you can – as if your life depended on it – you need to comb through its website and know everything about them – where have they been (look at company history, look at old press releases), where are they going (job postings may give you an idea about their future direction), read about the company in the news – what else are others saying about the company (don’t just believe what the company says about itself). Last thing you want to be is a candidate who is not prepared.

9) Company cheat sheet – Prepare on companies you have applied to as if the phone could ring at the very next second for an interview. I created a 1-2 page cheat sheet on each company I applied for so that I can have this information at my finger tips (in case the phone rang).

10) Company’s customers – Can you find a way to talk to some of the company’s customers? If the company has a discussion forum, you may be able to find customers there – what do they think about the company? How are the company’s products perceived? What is the future of the company in the eyes of the customer? If you do talk to their customers, mention this during your interview – it shows how well you research something, how comfortable you are talking to customers etc. – good companies value this and if they don’t, it may not be the right place to work after all.

What about recruiters? I did not have good luck with recruiters – not that they are bad – but they are hired by companies when their own recruiting efforts have failed and hence recruiters only look for a round peg in a round hole – their clients give them specific requirements and recruiters cannot flex them too much to accomodate a candidate’s qualifications.

Tools that I used effectively:

1) LinkedIn
2) Indeed.com – it compiles jobs from different job boards and emails you a digest daily.

I did not find ladders.com useful – it costs a whole lot ($30/month) and it was not of much help.

There is nothing called “too much preparation” in job hunting. So prepare, prepare, prepare ….

Avoid excuses for not conducting customer visits

Customer visits have always been one of my pet subjects because the only way I have learned to deliver good products is by getting out of the building and talking to real people who buy or will buy my products. At SolidWorks, customer visits was ingrained into our working culture and all of us had an MBO of conducting six customer visits every quarter.

Jeff Lash has written a very good article on his blog titled Avoid excuses for not conducting customer visits. It is definitely worth reading.

Are you agile?

I have heard this question being asked a lot of times – do you use agile development methodology? How about scrum, how about spikes? I heard this asked yesterday. To tell you the truth, I have some idea what agile is but to me it sounds very much like the latest buzzword to me. In my product management career spanning 12 years, I have really not paid too much attention to what software development process my team uses. Instead what I have focused on are things like –

1) Is my development team delivering functionality that solves customer problems that customers care about?

2) Are they delivering it on time so that it satisfies my existing customers and can help the business meet the revenue projections for this year?

3) Is the team receptive to iterative input or to customer’s new requirements during the development cycle to change the functionality based on customer feedback during alpha and beta testing – without telling me that “hey it was not in the spec and it is too late to make changes” (I fully realize to meet schedules and quality, there is indeed a point where it is too late to make changes)

4) Does my development team create very frequent and usable builds (not fully tested and hence buggy in some respect) so that QA and product management get to play with it early to ensure that what is being built is what customers want and to provide iterative feedback (Believe me, I do not think there is anything called a complete spec because have written so many functional specs over the years, I consider it difficult to foresee all the different permutations and combinations when writing the initial spec)?

5)  Are they delivering functionality of good quality that customers can use?

To me, delivering usable products to customers  that help the customer be successful and helps my business to make more money, is all that matters. What you call the process, agile, scrum, spike, non-agile does not matter.

Like anything else, if your development team does not have the right skill set, no development methodology stands a chance to do what is needed to sustain and grow your business. So before one starts using the latest fad in development methodology or starts saying things like – if you are not using agile, you are doing something wrong – it would be better to ask the question – why do I need this new methodology? what current development problems will it solve? What benefits would it bring to my customers or to the business.? Such an assessment would be well grounded in objectivity and reality rather than getting carried away by this hype.

I am not saying “agile” is bad or wrong (I don’t know enough about it) but no process can fix a problem if you don’t know the root cause to the problem.

How best to ask for resources?

Imagine that you have to make a business case to your upper management for a product/project you want to get funded. There are two ways a product manager can ask for this:

1) I need $$$$$ and XXXXX number of people to do this project?

2) I have this idea that I have vetted with customers and prospects, here is the total size of the market, this will help us move the business forward, this would establish us as a market/thought leader, here is potential revenues we could bring in, what do you think and do you agree we need to do it?

Which do you think is going to be received well? Of course answer 2 (provided you have done enough research). The obvious question that will be asked would be – what would it take? And the answer is 1). But going in there with guns loaded just with 1) is not going to get anywhere.

The other benefit with 2), is you are asking for input whether it is the right thing to do – you are engaging your management to help you make the decision. Once you have the buy in that the idea/product is worth doing, they will open up for your justification for resources. But the common mistake made by product managers is doing 1) with no luck.

State of You?

As a product manager, you are quite busy doing product roadmaps, gathering requirements, working with cross functional teams, getting the messaging right,writing positioning statements etc. You are busy trying to do all the work with less time and resources available at your disposal. In the midst of this chaotic professional life, have you taken the time to evaluate how well you are doing growing your career, building value for yourselves such that your market value is increasing? Yes, the first and foremost thing we should focus on is building value to our employers (that is what we get paid for), but it is also important that you spend time adding value to yourselves. After all, I doubt that most of us want to do the same thing and work for the same employer for the rest of our working lives .

One technique that is useful is creating an honest assessment of the one product you are in full control of – YOU!!. The way I did it the other day was to create a list of all the skills an ideal product manager should have (if you don’t know the full list, read a bunch of job descriptions for product managers in your industry and look at the requirements or skills being asked for and then create the list) and then made a honest assessment of where I currently stood on a scale of High, Medium and Low (High = strong, Low = weak). I also did an assessment of what my personal interest is for each of these skills. For example, as a product manager, one is required to help legal with contracts – I consider this as a necessary evil that I as a product manager has to live with, but not something I want to get very good at. On the other hand, product positioning or market sizing is something I have great interest in and should have a strong skill.

Once you do this exercise, your strengths (High skill set, high interest) and weaknesses (low skill set, high interest) is going to stare at you. Now you need to create a roadmap on how you are going to work on your weaknesses and figure out what projects you may want to take on (read “initiative”) at your current employer to add more value to your employer and yourselves.

I have done mine and found this very useful and I intend to use this once a year to evaluate my progress and analyze the State of “Me” going forward. The above technique can be used by anyone – engineers, scientists, doctors etc. and not just product managers.

3 types of words in positioning statements

Other day, I was talking to Jon Hirschtick (founder of SolidWorks and my previous employer) and we were talking about positioning statements. Jon had an interesting way to put it – he said words in any messaging consists of three types of words:

  1. Blather words: In other words, marketing buzzwords – integrated, extensible, scalable, value added, synergy, paradigm, next generation, flexible, configurable etc. – so commonly (mis-) used that it adds no differentiation to your message
  2. Glue words: Words that you are forced to use such as “and, or, the, with” etc. Does not add to your message but necessary to hold your message together
  3. Keywords: These are the real things. This is where you need to spend your most time carefully picking them. Choose simple words that communicate the essence. Use what will resonate with the audience, words they can associate with, words that will stick with them.

Jon has put this out in very simple terms that this will be my guideline in all messaging that I do from now – positioning statements, key messages in my presentations, marketing material etc.

%d bloggers like this: