Tag: product management

Effectively managing your communication with your manager

In the past 4 years, I have had 5 different managers – CEO, CTO, CMO and 2 VPs of Product. By the time I had got adjusted to the style of my manager and established a working relationship, I had a new boss. This constant change has made me come up with a way that ensures my communications with my manager is effective especially given the different roles they have held. There are three elements I have proactively established with each one of them to ensure no surprises

  1. Depth of communication
  2. Channel of communication
  3. Frequency

Depth of communication – given their different roles, I find out upfront how much detail they want to know on the progress I was making or problems I am encountering. Do they just want to know “release is on track” or do they want to know the the status of each of the features in the release including which ones have been completed, in dev or in testing? Establishing this upfront helps alignment of expectations and prevents surprises later.

Channel of communication – now that the content depth has been established, I then establish how my manager wants this to be communicated. Do they want it by email? Skype? Some managers would like to get a status update the night before my 1:1 and others have requested an update during the 1:1.

Frequency – this is where I have made sure my manager knew about my style of communication and was aligned with me. I classify problems into three categories and communicate it accordingly:

  1. “House is on fire” issues – these are serious issues that need to be escalated as soon as possible, issues that need to be handled above my pay grade. These are rare but when they happen, I will chase down my manager to communicate the issue face to face or give them a call.
  2. Important but not urgent – If it cannot wait till my next 1:1, I send it to them via their preferred communication channel (typically email) so that they are in the know and can provide me a decision or guidance I am looking for.
  3. Normal, “run the business” issues – I keep a running list of things I want to talk to my manager about during the next 1:1. If I feel that some of these issues require some thinking from their end, then I send it to them before hand and label them as “talking points” for my 1:1.

I have had great success using the above techniques, so hopefully you will find it helpful as well. Thoughts? Other techniques you have used that work well?

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?

Agile Product Owner – New Name, Same Old Problem

This is a guest blog post by John Mansour, Founder and Managing Partner of ZIGZAG Marketing

In the world of agile software development, the confusion over product owner versus product manager is hardly new. This problem has existed as long as software and product managers have been around. It merely has a new name.

First, let’s cover the basics. There are two key roles in the software product delivery continuum that must precede the first line of code being written, regardless of development methodology.

  1. The “what & why” role – responsible for determining “what” functionality should go into a product and “why” from a market and business perspective. The “what and why” role serves as the conduit for all inputs both internal and external. The end game of this role is to grow revenue by aligning product direction with market dynamics and customer needs. The “what & why” function is typically the responsibility of the product manager. Traditional or agile, it’s necessary regardless of who does it, their title or how it gets done.
  2. The “how” role – responsible for determining “how” product features should work to support the things users do. In its most basic form, this role is a surrogate user responsible for explaining in verbal, written and illustrated forms and in excruciating detail, what users do, how they do it and how software must work “functionally” to support the users. They spend most of their time with developers and they test functionality to make sure it works as designed, along with a host of other responsibilities. And yes, the best people for this role are former users or those who have worked intimately with a variety of users in multiple environments.

The “how” function is typically the responsibility of a functional product designer (for lack of a better title). For the fraction of software companies that have them they go by such titles as Business Analyst, SME (subject matter expert) and Technical Product Manager. In an agile environment they’re called Product Owners. Call them what you want, every company with high user interaction products needs them. They get much of the credit for things like iPhones and TiVo where the cool factor is the usability.

In my humble opinion, the confusion lies in two areas. First, software companies have been trying to combine responsibilities of the product manager and functional product designer for years and it’s a nightmare in every single case I’ve ever seen, and I’ve seen a lot. Plus it creates the same identity crisis as the product manager vs. the product owner in an agile world.

Regardless of development methodology, combining these roles is a recipe for failure because the skill sets and personality types required are distinctly different for each, not to mention the time commitment. When combined, the end result is either the right functionality with poor usability or highly usable features no one cares about. A dilemma on par with, “would you like to lose an arm or a leg today?”

The bottom line – your products will eventually fail. Second, “product owner” couldn’t possibly be a worse title, given the responsibilities of this role. Furthermore, product managers have always been affectionately referred to as product owners because they “own” the ultimate success of a product. Perhaps a dope-slap is in order for the person who coined the title “product owner.”

In summary, two distinct roles are necessary to feed requirements to software developers if you want usable products the market will buy, regardless of development methodology. The titles are less relevant as long as the responsibilities are clearly defined. For more on functional product designers read the article titled, Product Management & The Functional Designer – 3 Reasons it’s a “Must-Have” for Successful Products.

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.

%d bloggers like this: