What is a product manager?

October 15th, 2013 § 0 comments § permalink

I’ve been a product manager for a number of years now, and I still have trouble describing what I do. I tend to say “I’m the bridge between the different parts of a business – the executive branch, marketing, development, customers – and it’s my job to make sure the product speaks to and for all these segments.”
I usually get a puzzled look and then go into detail about various aspects of the role. Usually though, when the conversation is over, I walk away feeling like I didn’t do a good job of describing what I do.

It’s been a challenge. How does one succinctly describe a role that has so many different parts to it? Not just that, talk to two product managers and you’ll find that their responsibilities in their respective roles can vary widely.

Which is why this article grabbed my attention – Product Managers: Who are these ‘mini-CEOs’ and what do they do?

Specifically these bits:

Both Norton and Elman agree that the PM’s job is to help execute the company’s vision. In a way, it’s almost like they’re the mini-CEO, complete with the influence, but no authority — they aren’t the direct supervisors of the engineer or designer and can’t fire anyone for not following through, and focused on the success of the product’s mission.

 

What’s more, while a PM can be a mini-CEO, their responsibility is to make sure that the product not only matches up to customer expectations, but are also in line with the overall strategy set forth by the company’s founders and CEO.

I’m gonna adopt the definition put forth by Norton and Elman in my future conversations, and see if I find more understanding.

Meanwhile, if you’re wondering what a PM is, what they do and how one might contribute to your business, I highly recommend reading that article and the additional references in it.

So now you know what a product manager is and think you need one? I can help 😉

Keep in touch with the real world

October 7th, 2010 § 0 comments § permalink

The thing about being ‘tech savvy’, whether as a builder or a heavy user, is that we can get very caught up in how WE use stuff. Which can lead to a very myopic view of product and product design, to state the bleeding obvious.

The good news is that computer/web users are all around us. It’s super simple to keep in touch with how the average person uses virtual stuff. And since I’ve been doing a lot of it lately, I thought I’d share my simple research skillz with ya.

  • Stalk your close ones. Always keep an eye on how your family, friends, people you live with navigate sites. You’ll be amazed at how differently they do a Google search or get to a YouTube clip compared to… well, you. Example: I NEVER go to Google.com as a starting point…. people around me on the other hand….
  • If you’re anything like me, you might not have access to as many ungeekified people as you’d like. This is where stealth stalking comes in handy. Hang out at cafes, libraries, airports, anywhere you might encounter a bunch of people tap, tap, tapping away. You can glean a lot by glancing at your neighbour’s screen every now and then. (Not too much – the point isn’t to freak them out)
  • Pay attention to how customer service people behave with their machines. See, gives you something productive to do while in line, instead of resorting to queue-angst tweeting. 😛

There’s a wealth of information out there, and all you need to do is observe. Umm… and then apply obviously. I guarantee you’ll be more aware of the fact that your experience of the web is markedly different from most others’. At the very least, it’ll provide different perspectives. At the best, what you’ve seen will haunt you when you next draw up a user-flow chart or wireframe.

Saying NO to your customers

October 5th, 2010 § 4 comments § permalink

A friend brought my attention to this article this morning – Frito-Lay Trashes SunChips Bag After Biodegradable Packaging Criticized For Being Too Noisy. Quick summary – Company brings out new biodegradable packaging, customers think it’s too noisy and start making noise on social networks, company caves and reverts to old-bad-for-the-environment packaging.

Now, I’m a big proponent of listening to your community and feeding its responses back into product development. But here’s the catch. This process only works when you, the company or product manager, are willing and ready to say “NO”. Which is what I think Frito-Lay should’ve done in this case. I’ve thought about it, and it’s what my response to the outcry would have been.

I should explain myself. Listening to your community is a great way to get insight into how they use your product, what they want from it, what would make the product ‘something-they-use’ to ‘something-they-can’t-imagine-life-without’. It’s a way to be there for and give back to them and have them come back to you.

That’s what I see as an organisation’s responsibility to their community. But it also has a responsibility to its product (and by extension its stakeholders).
First thing to recognise about community feedback is that it isn’t necessarily the majority viewpoint. In my experience, a majority viewpoint usually consists of the majority of ‘noisy’ members in a community. (Note: I use ‘noisy’ as a term of endearment.)
Second thing to recognise about community feedback is that it can be wrong. It can be wrong for the product, it can be wrong for the company’s strategy, it can be wrong for the greater good.

And so it’s okay to say no to your community. “No” doesn’t have to be a confrontation. Do your research, get a handle on how big an issue it is for what percentage of your customers. Use that when you explain your decision and how you came to it. State in no uncertain terms why one path is better than the other. (In this case, Frito-Lay have a trump card – “We’re saving the planet!!” Tell me that won’t guilt the most noise-sensitive person into agreement ;P) Suggest alternatives to make a transition smoother. (Use a bowl for your chips?)
Above all, be human. Allow your community to connect with you on that level.

Pro Bono: Keep your terminology consistent Facebook

August 24th, 2010 § 0 comments § permalink

Happened to land on a group’s page today and decided I wasn’t interested in their endless updates and I wanted out. After I finally found the path to ‘adios amigos’ (fyi – it’s a tiny link under the left side bar) and clicked on it, I got this:

Notice how it changes from ‘Leave Group’ at the start of the path to ‘Remove’ in order confirm that’s the action you want to complete. It made me pause. It made me stop and think “Hang on, I thought I was leaving the group. What am I removing??”

Once again, it’s small stuff. But it interrupts my flow. Don’t do it. Unless Facebook is doing it on purpose, to make me stop and think, maybe change my mind in the process…. Hmmmm…

So, Hot Tip: Keep your terminologies consistent throughout your app please.

Disclaimer: In case my bro sees this post and gets the wrong impression – the group used in the screenshot, Plato’s Cave, his venture which I totally and fully support, wasn’t the one I was leaving. That screenshot was taken purely for demonstrative purposes. 😉

Do sweat the small stuff

August 19th, 2010 § 1 comment § permalink

Some of the most common issues I come across on the web are the most annoying to me as a user yet hard to keep track of as a producer. These are what I refer to as the small stuff. The stuff that isn’t primary functionality, and easy to overlook in testing. The stuff that you as a regular visitor to your site might never encounter.

Example 1 – Dead ends:

I was trying to sign up to Anno Books, and I used a plus-address in the e-mail field. Of course, they had a ‘Verify your e-mail address’ step which I forgot to anticipate. (For the record – END THE SIGN UP VERIFICATION MADNESS!) They sent me the verification link, I clicked on it, and I arrived at this:

Few issues:

  • ‘Oops we seem to have a problem’ isn’t helpful. Was it my fault or yours? Do I need to do something to correct it, do I have to just wait for you to fix stuff? Web makers, please make your error messages as informative (and obvious to the eye) as possible.
  • This page is a DEAD END. What do I do now? Where do I go?? Think about it. Somehow I got to your page, was convinced to sign up, went through the sign up and verification process – and now I’m stuck. I invested time and effort, and this blank page is the difference between whether I ever come back and visit you or if I move on and never look back.

The fix: As much as possible, inform the user about what went wrong. If there’s something they can do to fix it, let em know. If it isn’t something they can action, give them a path out of the situation. A link to contact support, a link to check an FAQ, a link to your blog, where you put up downtime notices… something, anything!

Example 2 – WTF moments:

I added a secondary e-mail address to my Paypal account, and clicked on the verification link (in this case, verification = good) This is where that took me:

The issue:
My brain goes – EGADS!! What have I done?!?!?! – and alarm bells start ringing. It tells me I have activated my ACCOUNT, linked a credit card AND to proceed I have to link my bank details. Really, W T F?? I actually did think I did something to create a new account, which of course, was not what I was trying to do. And the call to action, the big yellow ‘Continue’ button would mean having to give more information I didn’t want to. My eyes didn’t even register the little ‘Go to my Account’ link on the bottom of the page.

The fix: Don’t FREAK ME OUT YO!! Make sure your links lead to the relevant pages. I’m sure that account created page works well for newly created accounts, but in this case, I should’ve been taken to a page that simply said ‘Email verified, Go to Account’.

The ‘high level’ fix:
The thing is, as producers, these things are easy to miss. When I first started at Tangler, I usually only found out about these when our members told us about it. That’s a great first step – listen to your people. If there’s a small issue, fix it, and this is key – add a test for it in your testing process. That ensures that any subsequent annoyances will be picked up.

The other thing I learnt to do as a product person was to take some time out and focus on the small stuff. I’d go into the system and sign up, change details, break things on purpose etc, just to see where an error led, if we could do anything to improve the landing page, or if indeed we had a dead end in a sequence. It became a fun past time, something I’d do between big releases to unwind. Doing this became key when we released TanglerLive. We all know it’s crazy times going live with a brand new product, and the small stuff is often forgotten amidst the madness. But that’s ok. No one expects you to get it right at first go. Just keep your eye on the small stuff as you go.

Why little features matter

January 15th, 2010 § 0 comments § permalink

Last night I ordered some takeaway, and after paying and being handed the dishes, I asked for “the chilli in the chilli oil”. I’ve learnt to be specific, because I’ve been handed just a little tub of chilli oil in the past, when what I really want are the flakes. (Them be yummy) I watched as the restaurateur proceeded to fill the little tub with chilli oil, so I said “Could I have more of the chilli flakes please?”

He proceeded to tell me that he couldn’t give me more because everyone likes it and wants it, and they never have enough and so he had to ration the portions. I looked at the big tub of chilli oil+flakes they had and said, “That’s not enough? Maybe you should get more!”
He gave me this blank look and went on ranting about how everyone asks for the chilli flakes and the chilli oil is just as spicy etc. I said “Yes, but the flakes are really yummy, and go with your dishes well. It’s why I come here!” So he grudgingly popped in half a teaspoon more. It was a friendly exchange overall, I smiled and thanked him and he sent me off with warm wishes. No issues.

But as I walked out of the restaurant, a thought popped into my head. “Might not come here again. It’s always such a hassle with the chilli flakes.” Followed the very next moment by: “Hang on…. stop eating here because of the condiment??”

I considered the situation for a bit. There are at least half a dozen similar restaurants on the block, most with similar food at comparative prices. Actually, that restaurant is a slightly pricier one. Their food is good, but the main reason I pick it over the others is for the chilli flakes. I can’t seem to get em anywhere else, and their dishes just aren’t the same without it. Judging by what the restaurateur said, others share my tastes. Why not just up the stock of chilli flakes?

I looked at it from the restaurant’s point of view. Their main product is their menu. As in their main dishes. Hunger is the need they fulfil and that is what they get paid for. The chilli flakes, those are just a feature. Like good service, clean plates, a phone-in order system. Secondary to the menu. There’s no obvious reason they should stock up on chilli flakes, especially when they have to give it away for free.

Turn it around to my (the customer’s) view. I am hungry, but I have a dozen options. I chose this restaurant because I’ve been there before and have been craving to return to its tastes. And the chilli flakes are essential to the experience for me. I’m willing to pay slightly more for that experience. My need isn’t just hunger. It is satiating the tongue. I considered never returning to the restaurant because that feature was getting hard to access. Would I pay for the chilli flakes? Nope. Do I want it? You bet!

And just like that, I get a lightbulb moment about my role as a product/community person. When I was only a community manager, it was easy to take feature requests. Every suggestion I saw was a great idea, a ‘why-didn’t-I-think-of-that’ exclamation, a ‘now-that-you-mention-it-I-really-really-want-it-too’. I wasn’t responsible for product decisions then, and I never understood just how hard it is to make the decision about which requests should be put in, and which had to be left out. (In fact, there might be testimony to the fact that I fought hard for every request a member made. :P)

Now that I’m that person, it is one of the things I struggle with most. I’ve caught myself groaning at new feature requests! (dek hangs her head in shame at this) One of the things I’m most wary of is feature creep, and by association feature requests. If not given due consideration, feature requests can lead to a never-ending road map, feature creep, which then leads to a loss of focus (and I learnt focus from the best – Dr Focus himself!), which then leads to a bloated product…. Before you know it, you’re designing a ‘lite’ version of the behemoth.

But it doesn’t have to be one or the other.
So modified rule – Focus on the core. But always be on the look out for the chilli flakes.

Join your troops on the front line

December 7th, 2009 § 2 comments § permalink

At the inaugural Product Mavens’ Meetup (#pmm) the conversation turned to support and the challenges we face in that area.

What really warmed my heart was the general consensus within the discussion that everyone in a company, large or starting up, should have a go at fielding support queries. On a personal level, attending to support calls is the single biggest stresser for me. I deeply dislike it when something isn’t working for someone trying to use our products. Usually, unless it is a major issue affecting a big population of your base, it is hard to convey a sense of urgency to the rest of the team. It’s always been my thinking that the process from receiving a support ticket to resolving it would be much improved if only everyone involved had a sense of exactly what is involved in responding to someone facing issues. Not only would everyone have a handle on the bits that are broken, but it supports your support people. And trust me on this – support peeps need all the backup they can get on the front lines. Things can get hairy out there.

Having a grasp of the issues one’s customers are having isn’t only about fixing bugs in the system. It is imperative for a good understanding of who is using your product, why they’re using it, how it fits into their lives, and consequently the direction your product should go in. Let’s be frank here, if your business based on a product, what can be more important? Knowing these things forces you to look at your product with different perspectives. For some, it is the reason they look at their product at all.

Which brings me to another point I think everyone in an organisation should do. Use your product. Simple, no? Yet I have observed a definite lack of practise of this. [I once had a conversation with a CEO of a startup about one of their features, and he had this blank look on his face. He had NO idea what I was talking about. He lost a few competency points in my eyes ;)] If you don’t know what you have, how can you possibly build upon it?

Now, my position is definitely coloured by my community management background. Using the product and answering support calls are part of what I do. I’ll admit that the reshuffle required in large companies for every cog to have a go at customer service is a huge task. There are ways to get around this. I remember someone at #pmm mentioning that there’s a company which makes all new employees serve a support stint before taking up their permanent roles. (Anyone got a name?) For startups, it could be as simple as getting everyone to check in on Jira or ~insert issue management tool of choice~. The point isn’t that everyone needs to be doing my job. The point is that everyone should have a handle on what’s actually going on with your product and customers.

What do you think? Am I off my idealistic rocker?

Oh, and before I end, heads up to the product peeps out there – there’s another mavens’ meetup on the 16th of Dec at the Trinity Bar. Big thanks to @mishymash and @schmediachick for organising!

Where Am I?

You are currently browsing the Product management category at dek's blog.