Me likes MyLikes

Have you tried MyLikes? It’s a generic social based recommendation service, where you can “like” virtually anything (e.g. a hotel you’d like to check out or a personal finance service) and share those likes with your friends.

I have to admit when I signed up when it first launched that I was intrigued but very skeptical. After playing around with it for a few times, I forgot about it and didn’t become a very active user aside from the occasional email notifications when someone I knew had “liked” something. But overall I wasn’t that impressed.

Now Bindu and Arvind have made some interesting additions to MyLikes, and I think they’ve stumbled upon an interesting model: you can get paid for recommending things to your friends. Clearly most people won’t make a ton of money by doing this, but there are some influential individuals out there who could do well with MyLikes, if they play things well. And I think a lot of companies could benefit as well, by seeding the eco-system with suggested “likes” and then have people tell their friends about it if they are interested. Assuming a perfect world, this is probably one of the strongest form of advertising one can find: a referral from a friend.

But that’s assuming a perfect world, and unfortunately it never is. I don’t know all the details of MyLikes’ approach, but I am sure there will be challenges related to spam and general honesty of the sponsored recommendations. How MyLikes deals with spam and ensures that there are incentives to keep the recommendations honest and legit will probably be a major factor in the company’s success. I wish Bindu and Arvind all the best in their exciting new venture!

[btw, given that MyLikes sponsors people to recommend stuff, including MyLikes, you might wonder whether this is just a sponsored blog entry so I can make a few cents, and I think that'd be a fair, paranoid observation :) and that's why I've decided to not include any referral links to MyLikes in this blog entry, just direct links - this is just me talking honestly about a product I think has some interesting potential - or is that perhaps defeating the whole purpose of MyLikes? I probably should have included a referral link... ;) ]

- Gummi

Product manager stereotypes to avoid having on your team

“But Joe the executive asked us to do it the other way…”

Continuing along the path of my previous post about What makes a good product manager for software development I wanted to talk a little about the last attribute, obsessive enthusiasm about the product experience. The challenge is that it’s often hard to notice whether a product manager has this quality or not. So here are my thoughts on how to spot this through negative qualities, i.e. if you see a product manager do some of the following things, they’re probably lacking critical product thinking, which is key to becoming truly passionate about the product.

First, a few words about critical product thinking. A lot of people like to chat about products on a very high level, with no attention to details or whether a particular aspect of a product matter to users. Critical product thinking is the opposite of that, when someone thinks really hard about the product offering in a critical manner and with the users’ best interest in mind. It’s when you accept no compromise in delivering the absolutely best product to users. And you cut through red tape to achieve that, if needed.

So here are some of the negative qualities to look out for:

  • “You can’t change that, it’s scheduled for delivery in 2 months so we have to keep working on it.” – ah, the Gantt chart wielding product manager who misunderstood his title for a project manager. Sometimes these types are good for keeping a schedule, but letting them be in control of the product as well is a horrible combination. Sticking to a schedule is never an excuse for delivering a sub-par product.
  • “I just had a meeting with our VP, and he told us to do the opposite of what we had decided, and contrary to what I said yesterday, I now agree with him.” – you remember this one from school, right? The Brown nose product manager is usually easy to spot and even easier to disarm. They mean no harm but simply don’t know better and don’t seem to have a free will when it comes to building a product; it’s all about what the executive says! The best way to fight them is to arm yourself with data and take the argument directly with the executive in question. A word of warning though: don’t ignore this syndrome, since that will only make matters worse for you (do you know what being held in contempt means?), your team (we’re not going to ignore our executives!) and your product (with no prior knowledge, the chances are 50% that your executive is right; assuming your team has prior knowledge about the product space, the chances are even worse and the users will suffer as a result).
  • “Here’s the PRD I created, how long will it take for you to build this thing for me?” – very few products nowadays are designed or built by a single person, it’s all about the team work. But somehow, the Dictator product manager doesn’t seem to get it. There are perhaps a few exceptions – Steve Jobs comes to mind as potentially the closest thing, although even he doesn’t seem to be a true dictator when it comes to product design – but even then I still believe true teamwork can make the result even better. This type is easy to spot, except when you have the Charming dictator product manager – all I can say then is “Good Luck” :)

There are more stereotypes to be aware of – do you have any to share? Any tips on how to neutralize these wannabe product managers?

- Gummi

11 concrete steps to zero inbox

I’ve blogged before about how to handle email overload, but people often ask me how specifically I would suggest do it. So here are 11 simple concrete steps showing you how to get to zero inbox and maintain it with not-too-much-effort.

  1. Sign up for Gmail. Yes, I’m biased, I work for Google, etc, etc. But quite frankly, I haven’t seen another email application that handles email as well from an overload perspective. Feel free to use any other email client, but your mileage may wary.
  2. Turn on Keyboard Shortcuts (in Settings -> General)
  3. Turn on Gmail Superstars in Labs (find it in Settings -> Labs)
  4. Pick Superstars for message follow up priority (in General under Settings); I use the following:
    Yellow star
    - need to follow up with this message at some point
    Blue star
    – in the “next to follow up” queue (usually means today or sometime over the next few days)
    Red exclamation mark
    (a.k.a. Red Bang) – URGENT, deal with immediately
    Orange ยป
    (a.k.a. Orange Guillemet) – waiting for someone else to deal with
  5. If you subscribe to a lot of mailing lists, consider filtering the ones with low SNR into a single label directly (I label this “non-urgent” and it catches about 70% of all messages I receive so they never even hit the inbox) – a handy way to do this is to open a message sent to the mailing list and select “Filter messages like this”

    Filter tip: make sure you specify “-your-email-address” in the To: section for all filters if you want messages sent directly to you to always go to the inbox, regardless of other recipients. Otherwise messages sent to you directly and a filtered mailing list will be lost.
  6. As seldom as possible*, open the top message in your inbox.
  7. If it’s something you can deal with quickly or don’t care about, hit the ‘[‘ key (archive-prev)
  8. If it’s something that will take a lot of time to deal with, or you need to work on, star it with the appropriate star and hit the ‘[‘ key.
  9. Repeat steps 7 – 8 until your inbox is empty.
  10. Switch to the Star view, and work on the messages there, or other important stuff you have to work on from your task list – these are concrete things you have to deal with, and now you’re free to focus on them without the distraction of new messages arriving.
  11. Every now and then (I do this every day or two), go through the “non-urgent” label (if you created filters) and skim through messages there and then remove the label from them. Most likely this won’t take long since the messages there are probably not that interesting or important.

* the frequency of checking your inbox depends on a) the amount of email you get, and b) whether your job depends on your timely responses to email messages (but this is usually not the case btw, even if you think so). I get a few hundred messages per day, and check my inbox 2 – 4 times per day (I vary the frequency depending on what is going on). The key is to minimize the amount of time you spend checking email, and part of that is not checking too often. I would guess that 1 – 2 times per day is perfect for most people.

I hope this helps dealing with the email overload. Btw, I think this is my first how-to blog post, exciting! :)

- Gummi

Thoughts on prioritization

Every product development team (and product company, in fact) spends considerable amount of time and energy on prioritization of its work. The obvious time goes into meetings, data gathering, discussions, brainstorming and so on and so forth, but the more hidden energy goes into second guessing the prioritization, getting buy-in, politics and other counter productive activities.

Getting this right is extremely hard, and there is no tool or set of tools that will make this easy and straight forward. Here are some suggestions that can hopefully help though.

  • Forget about the medium term. In my experience, the most successful (and efficient) teams are the ones that have a simple, clear long term vision, and then a specific short term tactical plan. Don’t waste time planning what to do 6 months (your horizon might be shorter or longer, depends on the industry you’re in) from now, since things will have changed so much at that point that it won’t matter. This alone cuts your planning time by half.
  • Make teams responsible for their own planning. The team building a product knows it the best, has the best insights into the users, the technology, and the market being addressed, and has the best incentive to create a plan that they can stick to. This does not mean that teams need to be fully autonomous and independent, but rather that external parties (other teams, executives, etc) should provide feedback and guidance, not hand down fully baked plans. This reduces that chances of second guessing sabotaging your plans.
  • Get data, but use it fwiw. Data is always good to inform prioritization, especially if its data from your own product (usage, bugs, performance stats, etc). Make sure everyone involved in the planning process has access to, and looks at the data. However, don’t let data dictate your prioritization, and be especially wary of inaccurate (e.g. from a shady third party analyst) or mis-interpreted data (e.g. a very vocal user on your user groups over-represents certain issues).
  • Let the team do the prioritization. Once you have this structure set up, and everyone has access to all the data, it’s time to prioritize. I like quarterly planning meetings, and I’ve used a range of methods for getting the releases scoped and lined up. One that I particularly like is to spend half the meeting (usually 30-45 minutes) getting everyone’s ideas on the table, and then the second half (another 30-45 minutes) voting (each team member gets 3-4 votes) which gives you a pretty rough but good idea of the order of how things and then you use that to scope releases of your product. This gets buy-in from the people who will be doing all the work, which is crucial.
  • Communicate the plan widely. Let others know what the team has come up with, and ask for feedback, but don’t let randomization happen. This step might require you to take some thoughts back to the team to align better with other teams or just to share some excellent insight that someone outside the team might have had, but it should hopefully not force you to do the whole process again (if that’s the case, perhaps the team is not that competent?) This should defuse most of the politics (although that’s always hard).

Is this scientifically accurate? No. Does it account for all user feedback, and ensure that the most requested features get built first? Not really, but sort of. The problem with strictly analytical approaches to prioritization is that you end up with faster horses, when you really want to build cars (building on Henry Ford’s famous quote), so be careful. This is such a fuzzy process anyway, that often just getting a rough order in plan is crucial, and allows the team to focus on execution and building the product.

Remember, a body in motion tends to stay in motion, so don’t get paralyzed by planning and prioritization.

Do you have any other insights into prioritization? Share your thoughts in the comments.

- Gummi

Outage!!

My blog had a complete outage over the past few days.

I guess you can expect this if you want to run your own servers on your own network in your own house… who does that anymore these days?!? Well, I do. And I do it because I’m having fun at it and that’s it.

The outage was caused by a failed router, and it took me awhile to replace everything so that my complete network could go up again, but now things should be rolling again. Here’s to an interesting and eventful 2010! :)

- Gummi

LEGO building lessons

This Christmas was a LEGO fiesta. My two daughters got lots and lots of LEGO boxes, and have spent a big portion of the past days putting things together. There’s a castle draw bridge, and a nice family house, and a police stations, and the list goes on and on. I’ve been a passive participant, occasionally helping out in finding a particular piece or interpreting how the layers in step 17 in the carefully crafted instructions add up to the observation deck of the police station.

I’ve also been thinking what a damn fine toy LEGO is, and how it prepares our children for the life ahead.

  • First of all, building LEGO models teaches patience. Take a box of 500 or 1000 pieces, many that look very alike (but still not the same), and follow 4 books of instructions, each 30-40 steps, in order to build a single house! For a 6 year old, that takes a lot of patience, but with it comes appreciation for the rewards of being patient.
  • Second, LEGO shows you how to follow instructions, but only for what it matters: in order to get results. You can spread the bricks randomly around your room, or you can sort them by size, color and shape. You can follow the steps strictly in order, or you can do steps in parallel by sneaking ahead. The instructions are there to help you get results: the model you’re building. If you achieve the results, the rest doesn’t matter. I wish more companies taught their employees the value of this. Rules are meant to be broken, as long as you achieve results!
  • Finally, LEGO teaches innovation. My six year old has built countless models by the instructions provided in the box. But she’s also built models by sight based on the pictures of models on the box that don’t have instruction manuals. And she’s also improvised and built her own stuff. With such a powerful and flexible toolset like LEGO, it’s impossible not to innovate. And that’s the most important lesson of them all, teaching children to try new things and build stuff.

Pretty impressive for a toy that was invented in 1949.

- Gummi

“I have a great idea, let’s f**k with our customers, yay!”

Why do companies do this? Imagine going to the coffee shop, and asking for a cup of coffee. Instead of serving you the cup of coffee, the barista acknowledges that you probably asked for a cup of coffee, and then goes on to tell you about all the other stuff they sell. You repeat your request, and the barista (clearly baffled at this point as to why you’d ask for coffee in a coffee shop) again acknowledges that you’ve probably asked for coffee, but just wants to make double sure that you really want coffee.

Sounds like a frustrating experience, right? And clearly something no company would ever do, right? I thought so, until I tried the customer service line for GAP. Here’s a rough transcript for my call, where I needed to talk to a human operator for some help:

GAP: Welcome to GAP customer service. To check the status of an online order, say order status. To learn more about…

Me: Customer service.

GAP: …how to place an order, say place order…

Me: Customer service.

GAP: It seems that you’re trying to reach an operator, but let me repeat what you can do in order to speed up your service. To check the status of an online order, say…

Me: Customer service.

GAP: Hmmm, you seem to be trying to reach an operator. To hear the options you have, say options. If you’re sure you want to reach an operator, say agent queue.

Me: Agent queue.

Sigh. The first time I went through this, I accidentally said “customer service” at that last prompt, and the whole process started over; better not make any mistakes. At the coffee shop, at least one could have told the barista to shove it in a dark place, and the coffee would have been promptly served.

- Gummi

How to force yourself to do stuff that matters

Earlier, I’ve talked about the power of deciding the 3 most important things to do at the start of every day. Of all the crazy GTD style things that I’ve done, I believe it’s the single most powerful thing you can adopt, and it’s super-super-super simple. And effective.

Recently I’ve found a new use for that 3-things-list.

Have you ever had problems motivating yourself to go to the gym? Or are you struggling to keeping in touch with your friends because you’re so busy at work? Whatever your suckness is, the list can help you change that.

It’s simple. Of the 3 tasks, make one the thing you know is important but you never do. “Go to the gym.” “Call a friend.” And so on, and so forth. And then when you’re done with it, feel the rush of checking the item of your list, knowing that you’re finally doing what is good for you and still feeling productive!

- Gummi

Marc Andreessen on productivity

Ron Feldman sent me a link to this old post by Marc Andreessen, recently re-posted by the Pmarca Archies.

It’s really good! And not to brag, but I already do a lot of the stuff he talks about, like keeping all my tasks in one place, deciding the 3 tasks to get done for the day, checking email twice a day, etc, etc. However, the one thing I would absolutely like to try is his idea about “no schedule.” Just do whatever is most important at any given time, and don’t tie your most valuable asset down by some other people’s needs in the future.

I can’t imagine myself being able to do that today, but I work with people who seem to do this, and I envy their setup. Perhaps one or two meetings per week, but otherwise just work on things that matter. Beautiful!

I need to find a way to be able to have no fixed schedule.

- Gummi

What makes a good product manager for software development?

I’ve been getting this question a lot lately: what do you think makes a good product manager for software development? (no idea why I’m getting this question more often these days :) ) And as with any question you get asked a lot (what’s your favorite color?) you start structuring your answer and eventually repeating yourself again and again (blue).

So I thought it would be fun to post it here as well.

Deep technical understanding

In order to develop software products, the product manager needs to understand the technology, often at a level of a very competent engineer. It’s necessary but not sufficient table stakes. Why is that so important?

First of all, people who don’t know technology and what’s possible and what’s not, tend to dream up crazy, hypothetical products. That’s exciting, but it’s hard when you have a team of pragmatic engineers with an arsenal of real technology who need to build a real, working, useful product. Or you have the opposite problem of not knowing what the technology can do, and the resulting product doesn’t utilize the full potential of the technology.

Second, when you spend more than half your time working with engineers, you better speak like a geek, or else there won’t be any respect to go around for you. And no respect means no progress on delivering a product. Sorry man.

Speed of execution and juggling skills

Product managers are measured by the products they ship. And for good reasons, since that’s their job. Easy? Well, it’s just a matter of understanding what the user wants, measuring the performance of the product, working with operations, legal, production, strategic partnerships, business development and sales, etc, etc. And make it happen fast. Very fast.

The best product managers know how to juggle this mess, and understand that the best way to understand your product is to have a shipping product. So it’s important to ship early and iterate quickly. It’s a never ending battle, and it can be exhausting, but great product managers can never give up. The users need the product, and you need to deliver it to them.

Which leads us to the third, and arguably most critical ability of a good product manager…

Obsessive enthusiasm about the product experience

This is the one that’s easiest to understand, hardest to master, and most often lacking in product managers. If you don’t care, why should anyone else?

Why is Tivo easier to use than the run-of-the-mill cable company’s DVR? Why are some bank’s ATMs better than other’s? Why are Apple computers cooler than Acer’s? Because they care.

Obsessive enthusiasm makes you care about details. Obsessive enthusiasm makes you complain when you see the tiniest thing wrong. Obsessive enthusiasm gives you energy to make the product better. Obsessive enthusiasm is contagious. Obsessive enthusiasm makes the whole team build a better product. Obsessive enthusiasm will help you communicate about the product, and will get others excited about it, internally and externally.

This is not a laundry list, and there are other elements that matter as well. For example, being able to communicate on any level with various audiences in an appropriate manner is extremely important. But I consider these three broad abilities key. And they’re not check boxes; a good product manager needs to be very proficient in all of them, and can always continue to get better at all of them.

What do others think? Any abilities that are more or equally important for people leading product development in software?

- Gummi

 
Powered by Wordpress. Design by Bingo - The Web Design Experts.