Try my new side project (21habit.com) to track your New Year’s Resolution

A couple friends and I have just launched a project called 21habit. It’s a simple tool to help you make or break habits, 21 days at a time. In addition to helping you make a positive change in your life, we are also trying to raise money for worthwhile charities. You can help by trying out 21habit to track your New Year’s Resolution (or any other habit).

How it works
First, tell us what habit you want to make or break. This creates a 21-day challenge on 21habit.com. Check-in each day for the next 21 days to track your progress. You can stop or change the habit (or resolution) at any time.

While you can use 21habit.com for free, we also feature a Committed mode that we think will make you more successful, and also help raise money for charity. In Committed mode, you’re actually investing money towards your challenge. You start by investing $21. Each day you succeed at your habit you get $1 back. Each day you fail you forfeit $1, and we donate that $1 (all of it) to charity. You can stop the challenge at any time, and withdraw any funds not already forfeited.

That’s it, for now. I told you it was simple.

Where we’re at
21habit is a self-funded project that we work on in our spare time. We created it because we want to try to help people and charities, while learning and having fun in the process.

Our goal is to keep 21habit.com simple, and be thoughtful about what features we add. This is reflected in our simple design, without the bells and whistles of other sites. We’ll focus squarely on adding only the features that we think will make users more successful at making or breaking habits. We’ll listen to feedback from active users and evolve the site to serve them better.
My request
If you’re making a New Year’s Resolution, or simply have habits you’d like to make or break, we’d like you to give 21habit a try. The signup process is quick and easy. You can signup and start a habit within about a minute.

If you do try it, please tell us what you think at info@21habit.com. If you find it useful, please tell your friends about it by liking us on Facebook, tweeting about @21habit, or simply upvoting this post.

Thanks,
Ian (@ianmcall), and the 21habit team

16 Tips for Writing Upwards

If you're new here, you may want to subscribe to my RSS feed or follow me on Twitter.

These days my upward communications are almost always in the narrative format, typically 6 page documents with detailed data in the appendix. I've written dozens over the past few years and reviewed dozens more. These are a few things I've learned that I think have helped me write more effective docs. Whether you're writing for big company executives, boards, or V.C.'s, many of the same techniques may apply.

1. Identify Your Audience
A good doc has a specific audience in mind. The same doc will never be ideal for audiences up, across, down or out. Once you've identified the audience, many of the choices you'll make while writing the doc (e.g. altitude) will be much easier to make. In this post I focus on docs written to be circulated upwards.

2. Identify the Document's Goal
Documents should have a goal in mind. The goal could be to communicate an operational plan for the year, provide a status update, seek approval for a specific course of action, or explain the root cause and steps to prevent reoccurrence of a problem. Once you know your audience (but not before), and the goal the document is intended to achieve, you're ready to move on. If you're unclear on either then punt on the doc or clarify the audience and doc's goal with whoever asked you to write it.

3. Find Some Good Examples
Hunt around for other similar documents and pore through them. You may find some on your company's Intranet and you can ask around among peers for good examples they've written or come across. I guarantee you, if you read 10 docs you'll come away with a sense for which were effective and what you can learn (i.e. copy) from them. This is not cheating. Be aware that if you're writing for a particular exec or group that the format they favor might be different than the format favored by others. Find this out ahead of time if you can.

4. One Doc, One Author
Co-authoring a doc is painful, and the Frankendocs that result are usually painful to read as well. Collaborate on the outline, perhaps, but either write it yourself or have your prospective co-author write it. Don't tag-team.

5. Add an Executive Summary
Boil the entire doc down into a few bullets or a paragraph. Spill it. Your temptation will be to save the good stuff for the end of the doc to build suspense or get your excuses in ahead of time. Resist! If you are emailing your doc to a group of people many won't read the whole thing. The exec summary communicates the highlights, which is all some of the audience needs to know. For those that will read the whole doc the executive summary lays out the structure of the doc and answers key questions that might otherwise have clouded comprehension.

6. Take Time on the Outline
Just like it is quicker to fix a software bug during unit testing than in production, it is much more efficient to iterate of the outline of a document than to rework a fully written doc. I often ask my newer product managers to review the outline of a doc with me and incorporate any structural feedback I have before going on to write the full doc. Sometimes I even provide them a rough outline of what I'm looking to get from a doc to help get them started. Simple bullets are ideal. I don't want sentences or mini-paragraphs.

The outline should tell a story from top to bottom, and it shouldn't be flat. An outline with 16 sections at the same level isn't an outline, it's a list. If you find yourself with more than 5-6 sub-sections underneath any one heading consider grouping them. This gives the reader a framework to attach the information to, and helps them understand what to make of it. You'll know you're getting really good at outlines when you can go from the outline to the full doc by replacing each bullet in the outline with a couple sentences.

7. Add Themes for Structure
Themes are a great way to provide structure for a doc. If you're laying out an operational plan for the year you might want to communicate 2-3 themes for the year, why different themes will be focus areas in different parts of the year, and how resources are going to be allocated between the themes. Themes take a doc from the 100,000 foot view to the 10,000 view. If you skip them, then you risk losing your audience between the high-level content and the tactical content; they don't know how they got there.

8. Anticipate Key Questions in the Main Content
As you write the individual sections, take the reader from the 10,000 foot view to the 1,000 foot view. Start with the minimum amount of content necessary to achieve your goal. Use plain words and declarative (not flowery) language.

Your content will prompt questions from the reader. Try to anticipate what those questions are likely to be and answer them immediately after they're likely to be arise from your content. If you don't, the reader will be distracted as they read the rest of the doc looking for the answer (at least I am). I try to include one level of answers in the doc, but anticipate the second, deeper round of questions and have the answers to those in the appendix or in my back pocket (figuratively).

9. Use Numbers
Never use words like "huge", "large", "rapid", "tiny", "significant", "meaningful" alone if you can accompany (or replace) them with a number. Which statement communicates more information?

"Sales grew at a rapid pace in Q2."

or

"Sales in Q2 were $12.5M, an increase of $2M (19%) over Q1 and $4.5M (56%) over Q2 of the previous year."

Also, get in the habit of providing absolute values as well as percentages. Don't make the reader whip out the calculator app on their iPhone and figure it out for themselves. Finally, if you're communicating the change in a percentage value (e.g. conversion, attrition), give the change in basis points (bps), not another percentage.

"Gross margin grew by 10 bps, from 3.2% in Q1 to 3.3% in Q2."

is easier to parse than:

"Gross margin grew by 3.1.%, from 3.2% in Q1 to 3.3% in Q2."

10. Use TK's for Flow
While you're writing the doc, don't stop to dig into your Excel spreadsheet or plow through your email archive to find that specific number you need. Use "TK" (short for "to come") in place of the number, or highlight it, or add a comment to the doc and fill it in later. If you're on a roll and in the flow state writing the doc the last thing you want to do is context switch. Exception: If the value should impact the outline or the story you're trying to tell in the doc then find it out ahead of time.

11. Avoid Weasel Words
Replace "may", "might", "plan to", "possibly", "close to" with words like "will" or other replacements that add accountability. Which statement builds confidence more?

"We expect to complete project X early in the year, which may generate hundreds of thousands of new customers."

or

"Project X will be completed in April and generate 340K new customers through the end of 2010."

12. Review for Inconsistencies
After you've written the doc, review it for inconsistencies. Did you say that your themes for the year were going to be improving the product and then ramping up customer acquisition, but your roadmap has the big SEM spend at the beginning of the year and your hard-core prod dev work at the end? Do you say that fixing UX potholes is a priority for the year but have no specific projects or resources allocated to this area? Finding the inconsistencies in a doc is a skill that comes with experience. The people reviewing your doc probably have that experience.

13. Double-check Numbers
Explicitly double-check all the numbers in your doc again, backwards and forwards. Recalculate absolutes and percentages in both directions. Cross-check them against a different set of values. If your doc states that your cost for customer acquisition is $5 and you plan to add 100K new customers next quarter, does your financial forecast later in the doc have a line item of $500K for customer acquisition? If not, explain why the numbers don't add up or fix them.

Factual errors and wrong numbers in a doc can completely erode confidence in the doc and its author. People remember them.

14. Proofread for Spelling and Grammar
Duh. These make you look stupid and/or lazy. If your doc is littered with misspellings then it gives the impression you didn't put a lot of thought or effort into the doc, which can also erode confidence.

15. Put Details in the Appendix
Don't add a ton of graphs, charts, source data, or explanations to the main document body. Put the key stuff in the main doc and the supporting data in the appendix. If you find yourself putting content in the main body that changes the rhythm of the doc, then ask yourself if it is really necessary to achieve the doc's goal. If not, appendix.

16. Find a Friendly Reviewer
It's not cheating to have one or more people review your doc before prime time. Find someone who is really good at writing docs (especially for your intended audience) and ask them if they wouldn't mind reviewing your doc. Make sure to give them adequate time to review it (at least 3 days). Don't send them a half-baked doc. Don't have them review it multiple times. Don't ask them to keep reviewing your docs if you haven't incorporated feedback from their previous reviews. If you pick the right person, then the pre-review can flush out key questions you didn't answer and inconsistencies that you're too close to see.


I hope these 16 tips are useful. Did I miss any?

-@ianmcall

Top 10 Reasons Good Product Ideas Don’t Get Implemented

Have you ever had a really good idea about how to improve a product or website, and suggested it to the people who manage that product directly or indirectly (e.g. via a tweet)? Was your idea promptly implemented? If so, great! If not, then this post is addressed to you and intended to explain why not.

Below, I’ve listed what I think are the Top 10 (rational) reasons why good ideas don’t get implemented with the hope that you consider which might apply to your idea, rather than just assuming mismanagement, incompetence, or general asleep-at-the-wheelness (which also occur). You can think of them as a series of filters your idea needs to pass through to get to green-light. Unfortunately, as an outsider you will rarely have enough information or data to determine which reason your idea got stuck on. Sorry.

1. Your idea is a bad idea - Let’s dispense with this one first. Some ideas are just stinkers and would actually damage the product if implemented or be costly with no return on investment.
2. Your idea is a small idea or only affects a small user segment – This is a common one. Your idea helps users only a little bit, or helps only a few of them. There are bigger fish to fry.
3. Your idea is a solution in search of a problem – This is every presentation you ever saw at ETech. It is every technology developed without an end-user in mind, but with a customer bolted on later. You know it when you see it.
4. Your idea has unintended consequences – Your product idea is pure goodness, but its value is neutralized or minimized by a side effect that is pure badness.
5. Your idea is in a non-strategic area – Within every product or business there are strategic, investment areas and non-strategic areas. To win, businesses must focus their energy and effort on the former, which often requires that they starve the latter. If your idea affects a non-strategic area, it might be a great one but still doesn’t make sense to implement.
6. Your idea is not as good as other ideas – If a product is managed well, then your idea needs to be prioritized against many other good ideas. Your idea may get implemented, but only when the well of better ideas runs dry.
7. Your idea has legal or privacy obstacles – Plenty of good ideas have been rightfully killed by lawyers just doing their jobs.
8. Your idea has problematic dependencies – The dependency might be another internal product, a vendor, or a partner company. The problems might be political, technical, or financial.
9. Your idea is based on untestable assumptions (i.e. leaps of faith) - Note the distinction between untested and untestable.
10. Your idea would require a strategic shift – No matter how good, it may not be powerful enough to overcome the product’s inertia.

I hope this doesn't sound too cynical. In practice, the way around these barriers is to generate lots of new product ideas, quickly discard ones who fail one or more of these tests, and focus energy on those that make it through.

Drop a comment if you come up with other good ones I've missed.

-@ianmcall

Hard in Training - Easy in Battle

Brad Feld wrote a post recently called Preparing For A First Meeting With Me, where he gives folks some tips on what to do before, and during those meetings. Brad is a venture capitalist and, while he doesn't come right out and say it, the audience for this post are people asking him for money. It's good advice, and much of it applies to other types of meetings where you have an agenda. If you don't have an agenda for a meeting, then you should probably skip the meeting, or it means you're on Brad's side of the table.

Even if you don't think of yourself as a salesman, in most meetings you're either selling or buying. By selling, I mean there is something you're trying to achieve in the meeting that isn't certain. If you're selling, you should prepare. Next time you have a meeting where you are selling, make sure you...

• Know who you're meeting with and what their roles are.
• Know what their goals are. Know what motivates them. Know what will make them successful.
• Prepare your talking points, and tailor them based on who you're meeting with and what their goals are
• Anticipate the questions you're likely to be asked and prepare your crisp answers in advance.

Hard in training - easy in battle.

-@ianmcall

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