Generating New Product Ideas by Observation and Inspection

Having a tough time coming up with good ideas to grow your business? Here's an exercise you can try. First, do one of the following: read a blog post/article/biography, learn about another team or startup's success, or hear a great story. Second, ask yourself, "Is there some interesting nugget here I can apply to my business or product?" I tend to do this a lot, I can't help it. It's the lens through which I see the world.

Try to find something. Stretch yourself a bit, and try to find a thread and keep pulling on it. It's easiest when hearing success stories from other teams in your company who have similar goals and tools at their disposal, and who can share more detailed information about their success.

Probably the next easiest way to generate ideas is to take a close look at startups. Poke around a startup site, try to figure out their business model, see if you can guess the size of their selection or user base from hints on their site, see how they've addressed the hard UI problems in their vertical, take a close look at places where they've clearly defied typical design patterns on purpose. After taking a detailed look, take note of what is really novel about the business they're trying to build. Where do you think they're likely to crater? Have they done anything interesting that might solve the most glaring challenge facing them?

Once you've really inspected any of the above, then go back and look at your own product roadmap. Is there anything really great you just learned about you can apply to your product? Did you just spot a trap that some startup will fall into, that maybe one of your products might fall into also?

There is a difference between reading and learning, actually gaining knowledge. The technique above helps me fix what I've read or observe in my brain, and those nuggets often surface later in new contexts.

Give it a try.

-@ianmcall

F*** Your Plan

I've got two points to make in this post, maybe more. First, you can't f*** your plan if you don't have one, so make one. The process is useful because it forces you to look out into the future and consider where you're trying to get to. Once you know that it's easier to figure out what the milestones along the way are going to need to be, and in what order they need to happen. The process can, and should be hard. If you're doing it right you'll find problems in your initial plan. Milestone 3, leads to 4, leads to 5, but it turns out you need milestone 5 to be accomplished to achieve milestone 3. Back to the drawing board. Better to go through this process yourself than have some exec or v.c. do it for you - or the market.

Second, you need to realize that a plan is a snapshot based on available information at the time, which is imperfect. You just can't wait until you have complete information, because it won't happen. A little ways into your plan something is going to change from your initial assumptions; you'll ship late, you'll get a wave of unexpected customer feedback, your product will be unsuccessful, or wildly successful, you'll sign a major deal or one will get terminated, a competitor will throw a curve-ball at you, whatever. Something is going to potentially invalidate your plan. You can do one of two things. You can plow ahead with your plan (because it's a plan, right?), or you can adapt your plan to the current environment. Ultimately, the people that do the former, or are slow to shift to the latter, will be unsuccessful.

It might be a matter of moving some projects around, axing projects completely in favor of new ones, or drawing up a new plan from scratch. You may lose a few points initially when acknowledging your past plan has been invalidated, but you'll gain points in the end because you'll have a better shot at achieving results with a new or revised plan.

Finally, by making a plan and establishing goals, you're creating an extremely valuable learning experience. If you miss your goals, you'll be forced to look back at your plan and its assumptions, and determine where you went wrong. You can then apply this lesson learned to the next cycle. If you never planned, you would never have been off-plan, and you wouldn't have learned anything from it. And if you're not continually learning and getting better at what you do, it is you that is f***ed, rather than your plan. Your call.

-@ianmcall

Decoupling the Problem Child

Sometimes you have a big project that has to get buy-offs from other internal teams, plus approval from your management and possibly executives. There will be a few different pieces to the project, some that should be a slam-dunk, and others that are likely to prove contentious. Before you start down the buy-off/approval process, ask yourself, "Is there a way to decouple the strong piece from the problem area?"

If you plow forward with a single, monolithic project you're likely going to be caught up in review cycles for additional weeks or months while your dev team works on less important stuff. If you can decouple the two you have two options:

1. Parts A and B - Review both projects together in each round, but clearly delineate them. With each stakeholder, seek to gain approval for both pieces, but if part B gets stuck, try to get buy-off on part A.
2. Projects 1 and 2 - Move project 1 through the phases and try to achieve final approvals as fast as possible. Behind project 1, schedule a second round of discussions around project 2. That way project 2 can get mired while project 1 sails forward.

You have to use your judgment about which approach is the best, just beware that if you choose the Parts A and B model, you might be forced to couple them back up - badness (potentially).

-@ianmcall

Why Some Ideas Should Die

Scott Berkun put up a post the other day titled, Where do Your Ideas Die? He tries to make the point that for companies who want to innovate, lack of ideas is rarely the problem. Instead, the problem rests with the bottlenecks in the creative lifecycle. Apparently, according to his commenters, I'm (or managers/business owners like me) the bottleneck - the manager who refuses to fund the many good ideas sent my way. Here's my take on why seemingly good ideas don't get funded.

• You're lazy - You've only fleshed out 1% of what needs to be fleshed out to fund an idea, leaving the other 99% for your potential sponsor. Here's an example, "We should leverage social networks." You don't have to spend 6 months writing a business plan around your idea, but see how far you can take it before handing it off. You'll learn in the process and your idea will have a much better shot at getting funded.
  
• The Idea Has Been Explored Previously - Unless your idea is truly groundbreaking, it's likely the team that owns the particular area has already considered it and decided not to pursue it (or maybe they did pursue it and failed).
• The Idea Seems Big, But Is Small - The thing you're proposing is a "good thing", but is small, in terms of amount of benefit per user or number of users affected.
• Better Things To Do - You may have a million dollar idea, but there may already be five or ten million dollar projects in the works (even if you're not aware of them).
• The Idea Will Fail - Unless you're a true expert in your area, in which case you can probably fund the idea yourself, someone else probably knows more about how your idea will fare in the market than you do. They have more experience, and better judgment/instincts based on that experience.

These categories were easy to come up with because they're some of the reasons ideas I've kicked out to other teams haven't been funded, and also the reasons why I haven't funded outside ideas in my space. Believe me, if someone sends me a truly compelling idea related to my business, I will absolutely pursue it.

Think your idea doesn't fall into any of these categories? Then here's what to do:

1. Flesh It Out - See how far you can take the idea. Try to model how many users might be affected and how it benefits them (and your company).
2. Mock It Up - Try to cobble together some mockups, either yourself or from a designer that you can trade for a bottle of Scotch. I learned to do this myself because otherwise I'd be going through Scotch like nobody's business.
3. Address the Risks - Try to come up with reasons why the idea might fail and see how you can mitigate those risks in your plan.
   

When you do pitch ideas to people in a position to fund them, but don't, make sure to ask them why they passed. Then, apply that information to your next ideas and try to make a better, more bulletproof case. Most importantly, don't stop trying just because your first few ideas don't find receptive ideas. Remember what Andre Agassi's dad told him when he was first starting to play tennis, "Son, just hit the ball as hard as you can. Sooner or later, they'll start going in."

In a future post, I'll talk about some ways to generate more (hopefully good) ideas for your own product.

-@ianmcall

How Could This Product Fail?

Before you start in on a project (or a new business for that matter), do you ever stop and think, "How could this fail?" If not, you should. A product manager and I did this recently and came up with a potential way a major project my team was working on might fail. As a result of exploring this case, we ended up adding another treatment to our split-test experiment that we thought would mitigate the potential issue. Now we'll have the data during the initial experiment rather than having to burn weeks repeating it.

If you explore ways a project might fail before you undertake a project, in many cases you might be able to dig in and get some data that will either alleviate your concerns, or prove they're valid. Even if you decide to proceed, this paranoia may lead you to add additional metrics that you can monitor.

What are different ways projects can fail? Hmm, let me survey some the ways my projects have (or might have) failed over the years:

• Lack of Distribution - Even if revenue or value per active user is excellent, overall value will be small if it doesn't touch very many. You can fail to gain distribution because you haven't inserted your product in a channel with very many users, or maybe you have, but it isn't attractive compared to other offers in the channel.
• Customer Apathy - You get your offer in front of customers, but they just don't care. They may try it and even register, but they never come back. Many "viral" products fall into this category; their viral success gets the product in front of people who try it, and then completely purge it from their consciousness.
  
• Not Incremental - The product gets used plenty, but its use displaces use of other products that generate equal or greater value per user. Inefficient.
  
• Unintended Consequences - One example, to alleviate confusion between two choices you remove one, and people who formerly chose the other option now choose neither.
• Low Coverage - Killer feature, when you have enough data to populate it, but it only shows up for one in a thousand users. No impact.
• Too Expensive - Even if the project is considered a win, you took too long to deliver and sucked up too many resources in doing so. You'd have been better off doing other stuff instead.
  

Many of these risks can be surfaced ahead of time by gathering some metrics and doing some forecasting. Some can't, but you can still use fuzzy risks in your cost:benefit equation which informs your project sequencing. You can also structure your project to address the biggest risks earlier in the process and potentially fail fast if you can't surmount them.

-@ianmcall

Is Your Goal Aggressive or Crap?

So you've gone through the process of setting a goal for your product and, based on your forecasting, you've actually assigned a value to it, maybe something similar to:

Increase total qualified leads 50%, from 300k in 2008 to 450k in 2009.

How do you know whether that goal is aggressive or crap, or how your boss is going to read the goal the first time she sees it? First, you need to know what your baseline is (and what your boss expects that it is). The baseline is what your product would do over the period if you sat on your ass and did nothing but keep the lights on. This is your organic growth rate based on existing momentum of the product and the business. While it may be easy to assume your baseline will be the same as the overall business, that's likely not the case. Your product has a life-cycle of its own and you need to know what phase it's in.

If you're setting goals by month, you might be able to quickly swag your baseline by projecting the slope and shape of your existing metric forward through the next period. If you're using years you can see how much air (growth rate) is between this year's and last year's metrics and project that rate forward.

Baseline Growth

In the yearly example above we're running +24% YTD in 2009, +23% for March, and baseline growth would put us +22% for the full year. That means that with the stated goal above we're not committing to growing our feature 50% in 2009, we're really only growing it 38% (50% goal minus 22% baseline growth).

Projected Growth

The graph above shows our baseline growth projection in yellow and our projected growth in turquoise. Knowing the relationship between growth from projects (air between turquoise and yellow lines) and baseline growth (air between yellow and blue lines) is key to knowing whether your goal is aggressive or crap. In this case, there's a good amount of air between projected and baseline growth, indicating the work you plan to do through the year is meaningful.

-@ianmcall

Offense vs. Defense Projects

I spend most of my time focused on offense projects, the projects that are going to get me closer to my goals. The goals could be around sales, users, traffic, conversion rate, penetration, whatever. Note that offense projects aren't just building new stuff, they can also be fixing stuff that's broken or reducing abandonment within a feature. If it grows your core metric, then it's an offense project.

Defense projects are the price of admission for operating your product. Fixing bugs or migrating to a new version of a dependent service or library that doesn't offer any interesting new functionality are examples of defense projects. Some projects can be both offense and defense, but they'll usually be more one than the other.

In my project prioritization I tend to want to stack the deck towards as many offense projects as possible, preferably ones with potential big impact that are quick to develop (low cost). I'd do this all day long. Unfortunately, using this method alone means the defense projects never get touched, assuming you keep coming up with new ideas for offense projects. The question then becomes how best to work in the defense projects? You don't want to try to get them all out of the way before moving on to offense because then you delay all the metrics goodness until later and miss out on some compounding growth. You don't want to accrue too much technical debt or do them at the last possible minute because then you lose all momentum from the previous offense projects and the team feels like they are on a slog. You also risk missing hard dates.

My method is pretty simple: time-box defense projects, and leave the rest of your resources to work on offense projects. Then, over time, see if you can sneak some small offense projects into the defense queue (sneaky, huh?) or make the box smaller (i.e. going from two engineers to one assigned to defense). You want to block off enough resources for defense initially to keep you head above water and make some gains. Ideally if they're fixing root causes faster than the offense folks can create them, they can pay down some technical debt, thus carving out more resources for offense.

The reason I maintain essentially two different backlogs, is that if I just used one prioritized by offense, the defense projects would NEVER make the cut. I have to have a separate backlog prioritized using a different heuristic, and then apply defense resources towards that separately.

What method do you use to prioritize projects?

-@ianmcall

The Right Goal Against the Right Metric

How do you measure the success of your product? Hopefully it isn't against the success of the company, or of even the larger org your product fits into, because they don't measure the success of your product - the one you have ownership of. Whether or not you're required to by your management, you need to pick a single or composite metric that measures the success of what you do - your business within the business. If you know what this metric is, then many of the decisions you have to make day-to-day as a product manager will be a snap.

Let's say you run the spam prevention team for a major webmail product. Your goal is "Reduce spam on the abcmail network", right? Wrong. First, because there are no numbers associated with the goal, and second because the phrase 'reduce spam' is too nebulous. Are you trying to reduce spam messages sent to abcmail account holders, or from them (that affects your mail reputation with other ISP's)? Do you care how many get sent to account holders, or only how many reach their inboxes? All account holders or only active ones? Is reducing any of these even possible, given a general increase in the volume of spam and increase in the abcmail account base?

If you think your goal is to reduce spam on the network then you'll come up with some ideas to prevent chunks of spam, but that spam may not be the most valuable spam you can prevent from the perspective of your users or your business.

I'll focus on the inbound case where you have to ask yourself, what spam do our customers care about, and what negative side-effects does this spam have on our business? Is user retention the main thing we're concerned about, or do negative opinions about our service spread by our existing customers negatively affect user acquisition? Let's assume that, based on our data and user feedback, we're most concerned about active user retention. Webmail users probably don't close their accounts and send a note to headquarters indicating that spam was the cause of their account closure, so we'll assume that ceasing to send mail from the account is equivalent to account cancellation. I'll call this 'account abandonment'.

So now we're part way there. Our proto-goal is to "Reduce account abandonment caused by spam". This is a very different goal than simply reducing # of spam emails received. It also focuses on active accounts, by definition, rather than all accounts, providing additional focus. From here we have to put a metric on account abandonment due to spam. I'll hand-wave here and assume that we've developed a metric called 'Badmail Rate' that takes # of emails marked by the user as spam plus emails deleted without being read, divided by all email, and we apply this against individual accounts. When an account is abandoned and this metric is above a certain threshold (say, 50%) we chalk it up to spam, below this threshold we chalk it up to other factors. I've included email deleted without being read because I assume large segments of users never use the report spam features of their webmail services.

So now our sights are set on Badmail Rate. We can look at the distribution of badmail rates for all active users and see what the right end of that distribution looks like. Now our goal is a real focusing tool. We can model the different projects we have in mind (something I'll discuss in a future post) and look at which we estimate will have the greatest impact decreasing our badmail rate, or at least the number of users who are approaching our badmail threshold.

In the real world we'd also probably have goals against the amount of outbound spam sent from our service, and likely another against overall volume inbound, but the difference between having one goal and three, is that with three we can make intelligent choices about resource allocation based on the impact of projects on one or more of the goals.

Now I've never worked directly on a mail product and I could be talking out of my ass here, but I did find it a useful exercise applying the goal-setting technique I use against a different domain.

-@ianmcall

The Focus and Purpose of My New Product Management Blog

This is the inaugural post on my new blog, which I've decided to focus on project management techniques, mainly related to consumer-facing websites.

I've wanted to start blogging again for some time, but took a while to decide what area to blog about. I'm inspired by bloggers like Andrew Chen and Eric Ries who blog about things they know and have real experience in, so I decided that I'd blog about something I know. I don't claim to be an expert at product management, but it is a part of my job and I regularly get a chance to learn from my successes and mistakes. When I interview candidates for other management positions at my company, product management is the competency I'm usually asked to judge them on.

While the blog will be focused on consumer web product management, I'll also digress occasionally to post on business development topics or comment, from my viewpoint, on how other web products appear to, or could be managed. This isn't a startup blog, but hopefully my posts will be interesting to people in the startup world as well as people like me who run a business inside a BigCo.

As for the specific topics I'll post on, I've mapped out about 15 or so to begin with. I took over a team recently and these roughly follow the areas I've been coaching the product managers who work for me on. The posts will explain my approach to each. Notice I didn't say the right or best approach, just my approach. I hope my posts elicit comments from others in the product management field with descriptions on their own techniques or pointing out potential drawbacks in mine. So please comment, and please send me suggestions for other product management topics of interest that we could have a conversation about.

-@ianmcall