It just works: iCloud

I'm a fan of the philosophy they take from a product development standpoint.  iCloud highlights that point. 

Apple iCloud was recently announced and the first little piece of functionality has rolled out.  The AppStore sync has now showed up on my iPhone and my wife's iPad.  Since we share the same login, all the apps I buy and the books she downloads all just automatically show up on each other's device.  As Steve Jobs said in his WWDC announcement, "It just works".   

With MobileMe, this wouldn't have just worked.  Before iCloud, we were always moving little things around between "the home computer" to get it to each device. We had to consciously deal with this. Which meant the app I was looking for was hardly ever on both devices. 

When the Apple Product Managers got around a table this time, they could have thought "Let's make our service more simple like Drop Box".  This would have been better than before.  You pick the things you want to sync, and they automatically sync.  No, they took it further.  They thought "Instead of making it 1-click to sync, let's make it NO CLICKS".  Automatic.  It just works.  You do nothing.  

The idea of going further and taking all the hard things off the plate gets big wins.  Not just making them more simple, but making them a non-issue all together.  This is where Apple shines.  They shine when they take it off the table completely.   

I've found the same in the last couple of years with the products we've worked on.  We shine when we take the complex things off the table completely.   For us it was "Let's not make ad optimization more simple with some nice shiny controls for the user, let's just make it automatic with no controls."  ROI is way up.  For packaging, we were in market talking about the nitty-gritty details of channel based advertising.  We packaged everything together and stopped talking about channels period.  We focused on what was really important to our customers instead of talking about what everyone else traditionally talked about.  Sales are way up.  

Sometimes, it isn't about making things more simple.  It is about removing them from consciousness.  Apple got this with iCloud.  

The Bag is Full of Good Ideas

A former colleague of mine once made the statement "The bag is full of good ideas".  I agree.  I've never found there to be a shortage of people giving opinions about new features or new product ideas.  I have my own massive list of product ideas too.  My team has backlogs that are a mile long.  

Most of this we will NEVER build.  

All teams have limited resources and time.  These are far more scarce than ideas.  And often, most "good ideas" are probably not that good of an idea anyways.  As I said before, execution is key.  

So how do you choose what the most important ideas are in your bag?  Which ones do you want to spend your precious resources on?

You need to understand your business well enough to really know what financially is going to get you furthest.  You'll need to balance short term tactical need and the strategic wins.  Keep it simple.  For me, the key is listening.  Listening to everyone.  But it isn't executing exactly what they are saying, it is know their motivations and the hurt behind what they are saying.  If someone is saying "I really need a new button over here that does XYZ", it isn't about adding a button.  It is about understanding that they think they need a button because they are forced to do some menial task over and over again and they want to make that task quicker.   Maybe you should find a way to remove the task all together.  Your job as a product manager is to see past "the button" and remove the hurt.  

You choose ideas based on listening, knowing what is going to get you furthest most efficiently, and keeping it simple.  

You notice I didn't mention doing a lengthy ROI analysis or official market studies.  You should know your business well enough to not have to rely on these lengthy tools.  But you should be out there talking to your customers and listening.  

Listen, see past "the button", and go ahead....reach into that bag.  

Cut it in Half

When you are building a website or app you should always be looking at how to cut out as many features as possible.  It isn't what features you put in, it is about what features you choose not to implement.  You see this mantra in how Apple has designed their great products (iOS, iPhone, iPad). As I've mentioned before, the scope of your project is the thing that you can most often control (compared to time and resources).  

A smaller set of features really helps you with multiple things.

1.  Keeps your development team focused.  This produces higher quality features and design.

2.  Easier for your customers to understand and use.  Most users don't use most of the features.   Build the features they would use at a very high quality. Simplicity of feature, simplicity of design.  Whitespace is your friend.

3.  Your go-to-market time is much less.  And you can then quickly see the response to that core set of features and make decisions on what you need to improve or add.  

37 signals has a good comment on this in their "Getting Real" book.  It says:

Stick to what's truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half. Pare features down until you're left with only the most essential ones. Then do it again.

I agree with this.  Look at your list and cut, cut, cut.  Call it whatever you like:  Minimal Viable Product, Phase 1, Core Features,  whatever.  Cut it down to the essentials.  

Product Roadmaps are Dangerous (37 signals)

Another great blog post by 37signals last week.  Discussing the problems that a roadmap can bring.  The biggest challenge that I find is overcoming the needs by other to know what is out ahead.  What is your vision?  Maybe it comes down to discussing vision outside of the roadmap framework.  But get in the habit of describing your vision in such a way to show your process of reacting to the most important needs at the time.  

I think this quote from the post really sums it up:

Instead of the roadmap, just look out a few weeks at a time. Work on the next most important thing. What’s the point of a long list when you can’t work on everything at once anyway? Finish what’s important now and then figure out what’s important next. One step at a time.

You can see the full article here:

http://37signals.com/svn/posts/2940-svn-flashback-product-roadmaps-are-dangerous

The Iron Triangle of Projects

Cost, Time and Scope: Pick two.  This is the typical balance that a product manager constantly has to deal with.  The iron triangle of managing projects.  

Time and cost are almost always fixed.  

Most of the time, when you are building software, you have some date that is out there you need to hit.  It may be a conference, sales commitment, training cycles, or corporate goals.  Schedule is almost always fixed. There may be some flexibility on schedule at the beginning of the project, but often, once the first schedule is told to someone outside of the dev team, that pretty much sets it in stone.

With cost, most often this is the amount of dev resources you have.  Most often, your dev resources are fixed.  Larger companies can move resources around teams, but that heavily effects other roadmaps.   Also, it takes too long to hire for a tactical project.  Cost just doesn't change. 

That leaves scope.  Scope is the most important part of the iron triangle.  This is the part of the equation a Product Manager thrives in.  Setting priorities and knowing what needs to get released to best address the market is key.  

Quickly figure out the schedule and the amount of dev throughput you have.  Then spend your time on scope.