I mean, literally, can you call up a list of email addresses in less than 2 minutes, without having to bug another person?

If not, this should be the next thing you build.  I’m serious — postpone core product development, postpone customer-requested features, postpone non-major bug fixes — and build an internal tool, stat.

KISSmetrics is (sadly) the first company I’ve ever worked for where I’ve had a customer search tool.  Somehow I survived without it.  But this is like saying that people used to survive dentistry without anesthesia — why would you inflict that upon yourself once there’s another option?

These are some of the things I was easily able to do recently that would’ve been major efforts in the past:

• Find out who recently signed up for our product and send out some random check-in emails.
• Find out when the customer who just emailed signed up, to be sure and strike the right tone in my reply.
• Filter to find the appropriate customers (based on integration, signup date) for my survey.
• Search for that person who complained on Twitter – are they a long-time customer or a brand-new signup?
• Search for “good brand name” companies so I could provide a variety of examples of how customers you’ve heard of are using us.
• Look up customers who logged in within a couple days of releasing a new feature so I have a list of people to follow up with individually.
• Look up customers who “got stuck” at a certain point in onboarding and email them to offer assistance / find out why they did not continue.

These may sound like simple things, but they allow me to do a lot of very quick research and to run a lot of tiny experiments (send an email to a few people, realize you aren’t getting the type of responses you wanted, revise and send to a few more, etc.).

I’m sure there are more feature-rich solutions that you can buy, but I’m not sure those actually serve the same purpose.  As an internal tool, this can (and should) be quick-and-dirty.  I have basic filtering and search capabilities; for everything else I export via CSV and futz with the data in Excel.  I don’t have a built-in record of every communication with a user (but since I send emails from Gmail, I can quickly make sure I haven’t bothered that person too much recently by searching my sent-mail).

If you want to build one of these, here are some requirements you may wish to consider:

• Free-form search with autocomplete
• Filter by plan level
• Filter by integration level (i.e. signed up / started configuration / fully getting value from product)
• Filter by recent signup (i.e. people who signed up in last 2/last 7 days)
• Filter by login (i.e. people who logged in past 7 days, 8-30 days, 30+ days)
• Filter by activity (i.e. trial period / active / canceled)
• Export to CSV

Some people say “yes” for several reasons — it biases the person to like you/want to give you favorable responses, it attracts non-customers who just want the reward, it makes it more like a job so the person is motivated to reduce the amount of time they spend with you.

In my experience, it depends on a few factors:

• What method you’re using to collect feedback
• What type of compensation you’re offering
• How much they know about your product

I’ll go through these one by one.

Paying for Surveys is Risky

Surveys, especially when you ask people to rate the benefits of something, or ask how likely they would be to use it, are extremely subject to rewards tainting.   People, either consciously or subconsciously, want to feel like they’ve “earned” their reward, so they rate everything more positively.

The other problem with surveys is their anonymity.  You’d think that would encourage people to be more honest, but in my experience the lack of a human face to the survey makes people more likely to lie, just pick the first option regardless of how well it fits, or skip questions.

Not offering compensation for filling out a survey will lower your response rate. But the people who care enough to fill it out anyways are likely to be your best customers (or prospective customers) anyways.  They’re investing their time to answer your questions because they care about your product.  10 people who care are infinitely more valuable than 100 people who are ambivalent.

Your Money Is No Good Here

I only recommend offering cash money in one situation:  if you are conducting face to face usability testing sessions and make the participants come to your office.   In that case, compensation is less about paying for their feedback and more about recognizing that they already had to pull out their wallet (to pay for gas/transit/parking) and likely skipped their own lunch hour to come to your session.

Otherwise, money attracts people who need money.  Sometimes these are your customers; usually they are not.   Because they know that this is a one-time deal, they have zero motivation to “do a good job” — that is, to answer questions honestly and offer thoughtful feedback.

My preferred forms of compensation are:

• I’ll follow up with a summary of what I’ve learned from everyone (if your interviewees care about this subject, this is super-rewarding)
• Free use of my product for X period of time

These are rewarding to precisely the right people: people who care about your product/niche.

Of course, sometimes compensation is necessary because you have nothing to offer people (i.e. you don’t have a product).  I strongly believe that if you run a good interview or testing session and really listen to your interviewee, they will get value. They’ll get to be listened to and get to sound smart and have some fun.  But they don’t know that upfront (and it would arrogant for you to tell them that.)  In that case I recommend Amazon gift cards.   You can deliver them via email and add a thank you message; very simple.

Leading the Witness

Especially in early-stage customer development interviews, I see people inadvertently “leading the witness”.  That is, they say upfront that they’re building a social network for gardeners instead of asking about the interviewee’s gardening behavior.  They mention online bill pay before they ask how the interviewee goes through the process of paying their bills.

This is actually a problem with or without compensation. Because now, your interviewee will tailor their feedback to what they think would be useful for you know in the context of your product.  But they are not the product manager.  We all know that customers are not good at articulating what they want, but now you have put them in the position to attempt just that.

The less you can reveal about your product, the truer your feedback will be.  OK, so that’s easy for an interview, but what about for user testing a product or dry-testing a splash page?  Same thing.

Bias is actually less of a problem here.  Yes, the interviewee will try to please you.  It’s your job to set the tone that what would really please you is to know in great detail how they behave, what frustrates them, what their needs are, etc.

You will also need to watch out for signs of them tailoring their behavior to what they think your product is.   If you hear things like  “I could see myself doing…” or “That seems like it would be useful…” or “Maybe I could use…”  — beware.  Those are projections, not real behavior.  But I’ve generally had pretty good success in steering people away from those with a reminder that I’d really like to hear about what they’re doing now.

So the answer, like most answers in product development, is “it depends”.  But hopefully these guidelines will you evaluate your feedback plan and decide when and whether it makes sense to offer compensation.

“Oh, no, let me explain how that works–”:  Strike 1!

“Actually, that text isn’t very clear.  What it should say is–”: Strike 2!

“The way we intended you to use that was–”: Strike 3!

If you have already had to explain away some part of your UI three times, you need to stop right there and fix it.

I’m not talking about perfectionism or premature optimization or working on details because it’s easier than tackling your big hairy problems. I’m saying, you have already crossed the threshold where you are spending more time compensating for a bad UI element than it would take to just fix the damn thing, already.

Stopping to fix small things is frustrating.  You know you’re taking time away from your core features, your big hairy problems, your differentiators.  You’re pulling yourself out of “flow”.  You’re asking your engineers to spend time on some tedious task that isn’t even a blocker per se.

Or is it?

Yes, your confusing UI that caused 3 people to email you probably caused 15 more to just silently abandon you.  But I talk about customers all the time.  Forget the customer for a moment!  Think about the impact of bad UI on your internal team.

Three bad things happen when you let bad UI go untreated:

• You start subconsciously thinking that your customers are idiots
• You focus more on what I want to build than on solving a painful problem for customers
• You put your hopes on big, risky, “perfect” fixes instead of thinking “how can we make this better NOW?”

Here’s a little example

Sometimes we get these pesky 500 errors on our website.  At some point, we took the time to make them at least look pretty:

But I kept emailing people who were concerned about whether the error on our website affected the surveys we showed on their site.  (It did not.)

The ideal fix would be to never show a 500 error, of course.  But that isn’t a fix I could make right now.

It took less than 5 minutes to write better error text and have a developer push it out:

I have a list of about 10 more similarly-sized fixes that I need to make this week.   It’s likely that none of them will single-handedly increase revenues, or turn a hater into a fan.  But if getting them done makes us 5% more likely to stop and say, “how can we make this better now?” about the next crop of little issues, it’ll be worth it.

I’m going to pull a number completely out of you-know-where and estimate that a full 20% of time in software companies is wasted on completing tasks to avoid the appearance of flakiness.

Product managers are pretty guilty of this, but they’re by no means the only offenders (and when product managers do this, it’s often because of a corporate culture that encourages it, such as bonuses being dependent on the % of your features that are completed and released.)

Here’s what happens:

• a need is identified – a new feature, a bug report, an inefficiency
• requirements are written and agreed upon
• work begins

– but then something happens.

Maybe further customer interviews reveal that the new feature isn’t really that valuable after all.  Maybe watching your usage metrics shows that the bug – as much as it may irk you – is not affecting your customers’ use of the product.  Maybe that improved database query really isn’t needed at current usage levels.

Whatever the reason, the conclusion should be clear: we should stop working on this.

But we don’t.

“We should just finish it – It’s bad for engineers’ morale to have a half-finished feature sitting around.”  No — it’s worse for morale to have a fully-finished feature released but still just sitting around (and probably cluttering up the UI and generating more customer support costs.)

“We may as well do it now even though we don’t need it yet.” No — when you DO need it, it’s almost certain that your needs will have changed and this thing you built months ago will need more hacking to shape it into a still barely workable solution.

“We shouldn’t interrupt development ‘flow’ to start on something totally different.”  No — ‘flow’ is not valuable by itself!  There’s no sense in building the wrong thing fast.

These all boil down to: I thought this was important -> If I admit that it isn’t, I will lose credibility and look like a flake.

And don’t do the weaselly version, either, where you silently lower the priority on tasks and hope people will forget about them.

Make an announcement: “We are no longer working on X.  Here’s why: we thought it was going to solve Problem Y, but [it actually won't/problem Y isn't actually much of a problem/it will, but problem Z came out of nowhere and we've got to tackle that.]  I’m sorry that we already invested time in this, but I’d rather change course than have us waste more time on something that is not needed.”

I say, flake proudly.  Don’t keep working on dumb stuff.

We were going to build the coolest tree house around. It was going to be 10 feet off the ground at floor level and have 120 square feet of space under roof… You’ve probably already guessed that we did not, in fact, build the Minimum Viable Tree House.  – Christian Wyglendowski, The Minimum Viable Treehouse

One of the comments caught my attention because it highlights a debate that I’ve seen going on in the startup community:

“under the current popular interpretation of MVP as promoted by Eric Ries, the sketches were the minimum viable treehouse”

Well… yes and no.  Calling anything a “minimum viable product”, in some ways, allows us to fall back into the familiar trap of writing a bunch of requirements and then building a bunch of stuff.

Maybe we should reassociate MVP with Minimum Viable Process, to emphasize that this is an ongoing, iterating cycle that never really allows us to rest in our comfort zone.

Minimum Viable Process Step 1: Validating Demand

The blog post author started with sketches for the product (treehouse).   That WAS the first minimum viable product, in that it successfully validated that there was a market interested in the product.   Sketches were drawn and the kids agreed that they wanted a treehouse.  (They could, after all, have said they’d rather just have a Nintendo DS.)

The problem is what comes next.  Having validated the initial demand, the next iteration should have been another small step.

Minimum Viable Process Step 2: Identifying the Minimum Viable Feature Set

The next step should be another Minimum Viable Product, this time with a minimum viable feature set.   In other words, with just enough “stuff” that the target market could actually do something.

This is hard.  It’s so exciting just to HAVE a prospective customer and to see THEIR excitement, that it’s tempting to just ask them for all the features they might ever want.   You may not even have to ask – they may come to you with lists of options and features and configurations.

The author let the target market do their own sketches, which were probably very cool-sounding but had little to do with the target market’s existing behaviors and needs.  And it wasn’t because they were kids – most people are not very good at identifying, let alone articulating, the features that they will use and be delighted by.

This is where observation (or “ethnographic research”, to use the fancy term) comes into play.  As the initial treehouse sketches were created, the author could’ve spent some time silently observing the target market for their existing behaviors.

This might’ve yielded observations like “target market likes being in small spaces”, ”target market does not mind dirt, darkness, broken objects”, and “target market frequently changes style and format of play”.

A good product manager would follow up those observations with a couple of hypotheses, like:

• “target market’s primary desire is for a place where adults will not go (either due to size constraints or squeamishness about cleanliness)”.
• “desirable space for target market must be simply designed so that it can accommodate multiple styles of play”

Sometimes it’s possible to validate those hypothesis through asking the target market, but often they need to get their hands on the real thing to provide the feedback you need.

Minimum Viable Process Step 3: Releasing the (Totally Embarrassing) Minimum Viable Feature Set

Ironically, in this case the creator and the original stakeholders DID actually identify the minimum viable feature set.

“Papa built our last tree house in a day!”, my oldest said.
“Yeah, but that tree house was a couple pallets and a ladder”, I replied.

Exactly.  A couple pallets and a ladder, available within a day, was the minimum viable feature set.  3 features: something to sit on, up high, ready ASAP.

You should build that — something so crude that it embarrasses you as a product manager or engineer — and put it in front of your market.

Since you’ve validated the desire for a treehouse, you know they’ll use it.

Minimum Viable Process Step 4: Repeat

And maybe two days later, they’ll come tramping into the house and say “the treehouse sucks” and you’ll ask why, and they’ll say “because it doesn’t have X”.

And then you ask how it would be better by having X.  And then they say “because then we could do Y”.  And then you build something that helps the target audience to accomplish task Y.  Which may or may not be the exact feature they requested, but it solves the correct problem.

Seriously, Why Can’t We Just Listen to the Customer?

I’ve heard a lot of people who try and jump from Step 1 to a full product: “Now I’ve validated my original idea and found customers, and guess what?  My customers know exactly what they want!  I’m going to spend 10 weeks building it and they’ll be so happy that I listened to them!”

There are definitely times when the customer is the expert and you aren’t.  They know what they need, and if you want to be successful, that is what you will build.   There are also (many more) instances where the customer doesn’t know what they need.

How do you tell the difference?  By understanding why.  If you don’t fully understand your customer’s existing behaviors and what factors are important to them, you will not be able to tell when a desired feature is incompatible with them.  And if you don’t know when features are incompatible with your users’ behavior, you won’t know when to say “no” and you won’t be able to say “no” effectively.

Let’s look at a couple of the features built into the treehouse:

Skylights: They provide light and make a room feel open, airy, spacious.  These qualities are highly desirable for adults, but not a priority for kids.  In fact, they’re actually a detriment — how can you pretend you’re in an underground cave or vampire’s lair with all that light streaming in?

High ceilings: Desirable for adults, who are taller and don’t like hunching down to fit into small spaces.  Not required for 4-foot-tall stakeholders.  In fact, if the objective of the treehouse is a “kids only” space, why would you want adults to fit inside?

Understanding the psychology of your customers would allow you to push back on these requirements in a way that gets your stakeholders to agree.  “High ceilings, huh?  Do you really want Mom to come up here and hang out with you?” “NO!”

So, there’s no ONE minimum viable product.  You can’t identify one thing and then stop talking to your customers and go build.  Because you’re not really building a product – you’re building an environment that supports increasingly educated guesses.

It’s uncomfortable to not have a “stopping point” – but it’s a lot better than watching that treehouse sit empty week after week.

The Formula

1. Look for markets where the existing solution is incredibly powerful but people dread using it, or feel stupid using it because they haven’t invested enough time in learning how. 

   You’ll recognize these when you repeatedly see people look sheepish and mutter, “I know I should do X…” or “It’s probably really simple to do X, but I just can’t figure it out…”

2. Define the Minimum Viable Product.  What’s the smallest set of features in this problem that people absolutely need to complete?  

   Look for the offline alternatives to the market-leading software solution – for example, what are the bill payment behaviors for people who don’t use online bill pay?  Circling dates on calendars, adding up numbers on scratch paper, sticking envelopes in the mail…  (In some cases, the MVP may not be much smaller than the existing solution, but just contain totally different features.)

3. Build an intuitive user experience that aligns with the tasks users most need to do.  Remember that this is an activity that people sort of dread, so make it beautiful!  Make it dead-simple.

    People should feel reassured using this new solution.  They should feel like it’s preventing them from making mistakes.

Some Examples

• Mint (Quicken does everything you need in personal finance. It’s also bloated and overwhelming.)
• TurboTax (For most people, doing your taxes by hand isn’t rocket science. But it leaves you with a looming sense of dread and fear that an honest mistake will send the IRS pounding on your door, audit forms in hand.)
• Flip (Hand-held video recorders have been around for years, but most people still don’t know how to share that video with Grandma in another state.)
• BaseCamp (Microsoft Project has every feature imaginable. It’s also so complex that, reportedly, even the internal Microsoft team working on Project doesn’t use Project for their project management – they use Excel.)
• PayCycle (ADP and Paychex are probably the right choice for larger companies with more complicated payroll options – but total overkill for micro-businesses.)
• Twitter* (Blogging is a big time investment. A forced 140-character limit frees you to share thoughts and links without feeling the pressure to be super-eloquent.)

* I include Twitter because I know a lot of really smart people that I’ve learned from because they use Twitter when they could never invest the time in blogging.  They haven’t invested in the “intuitive user experience” part at all, though – for new users, it’s totally unclear where they should start.

Why More Companies Aren’t Doing This

I call into evidence a quote from a couple years ago, when a friend was talking about FreshBooks:

“What a stupid idea!  QuickBooks has the highest Net Promoter Score of practically any software out there! People LOVE QuickBooks!”

People who have already invested in using the existing solution are often happy with it.  They’ve forgotten the steep learning curve. If you interview them, they’re much more likely to ask for additional features than to think about how the system they’re used to could be changed.

Your advisors and friends are likely to warn you off this path.  Why would you deliberately choose a smaller set of functionality?  At best, they warn, you’ll steal 1-5% of the market leader’s users – that’s not enough for an interesting business.

The trick is that, while you are entering an existing market, you will probably need to define a mostly new customer base.

(I don’t know, but based on Yodlee experience I’d be willing to bet that a very high percentage of Mint users are NOT ex-Quicken users but people who had NEVER used personal financial management software before.)

This means you need to find non-users, thoroughly understand their needs, and validate that there are enough of them, feeling enough pain, and enough willingness to spend money on their problem.  This takes a lot of legwork, and there are no “let’s check the Forrester research” shortcuts here.

Now, Go Execute

and when you’re successful, throw me a few shares, eh?

Sure, you’ve put together short-term and long-term product roadmaps, you’ve done SWOT analyses against your competitors, and win/loss analyses on sales efforts.  But there’s another major factor affecting your product’s chances at adoption and eventual success: the current technology zeitgeist.

By this I mean: the collective effect of people’s attitudes towards technology, usage patterns, access, expectations, past problems, what they’re reading in the mainstream news and hearing from their techier friends, what is socially acceptable.  All of these are constantly evolving, and it doesn’t take long for a tipping point to occur where a strongly-held belief from six months ago is now no longer relevant.

How is this critical to product management?  A good percentage of our requirements are actually assumptions.  We assume that, without feature X or rule Y, our product cannot be viable.  We assume that adoption policy Z will repel customers and prevent adoption.

A small example: Nine years ago, my products had a requirement to be fully compatible with Netscape 4. At the time, it was a correct assumption that eliminating support for that browser would make our products unusable by a significant percentage of Fortune 500 corporations whose IT departments had standardized on that browser. 

A bigger example: Eighteen months ago, one of my current company’s social applications was designed to mask individual usernames.  At the time, it was a correct assumption that the average consumer would consider it a massive privacy violation to have their name appear next to articles they’ve read.

Today, both examples border on the ridiculous.  But when you’re in the middle of managing a product, it’s easy to forget to re-assess these assumptions.  Even if you’re in an agile environment where there are releases monthly or semi-monthly, it’s easy to continue working under the rules of an outdated technology zeitgeist.

Make it a rule – mark it on your calendar – to re-assess the landscape quarterly.

That’s right – even three short months is enough time for certain elements to reach a tipping point.  (Personal example: within the 3 months after the iPhone release, I’d estimate that the percentage of my friends with mobile web access went from 20% to 90%+.)

How to Do a Technology Zeitgeist Assessment

Each product manager will have their own sense for how important individual elements are to their product’s adoption.  But these are general guidelines that (to some degree or other) affect pretty much all products.

Ask two questions: Has this changed? and Is this gradually changing? in the following areas:

• Concerns about personal privacy / What’s acceptable to share publicly?
• Expectations around how companies protect data privacy
• Technology access: broadband, CPU power, hours/day with Internet connection
• Comfort levels with using your type of product (novice to expert ratio)
• Where people are finding out about your product
• What factors influence the decision to use/not use your product
• What are consumers willing to sacrifice for convenience
• How fast/dynamic/personalized do consumers expect products to be?
• What technologies are supported by the lowest common denominator of computer/browser/Internet connection?
• Expectations around visual design (what’s “professional”/”fun”, etc.)
• Age of your average consumer
• Location and frequency that your average consumer uses your product

I’m sure there are more out there!  Please add your “technology zeitgeist” elements in the comments.

If you work for a tech startup, you know that the smartest thing to do is “fail fast” - devise a hypothesis, figure out the quickest way to validate it, and, when it doesn’t work out, scrap it and learn from it to move on to the next, improved hypothesis.

“If you review your first site version and don’t feel embarrassment, you spent too much time on it.” – Reid Hoffman

“If everything seems under control, you’re just not going fast enough.” – Mario Andretti

Everyone loves to talk about “fail fast”, but how do you do it?   Ideally, you started out with a specific metric or criteria to meet – but not everyone planned that well from the beginning (and some of us inherit others’ poorly-laid ‘plans’).  How do you recover and move on from there?

How do you know that what you’ve got now isn’t working and isn’t salvageable?  Here are 5 signs that it’s time to move on:

1. The environment has fundamentally changed. The Hummer had unique appeal, but not enough to compete with the one-two punch of $4-a-gallon gas and environmentalism becoming increasingly mainstream.  Even once gas prices fell again, the damage was done.
2. You’ve captured the market – and it’s not big enough to sustain your business. Lots of successful companies cater to a niche audience.  But to be profitable, that audience has to be willing to pay more than it costs for you to sustain the product/service.  (Rocket science, I know!)  If you started out free, you may not be able to move them to “pay”.  Or a specialist audience may demand feature development and support that drive your costs too high.
3. Your product doesn’t have sufficient adoption to create value. Any product that relies on people – social networks, collaboration tools, knowledge bases, review sites, communities – are virtually value-free until they hit critical mass.   If your product doesn’t encourage viral distribution and low-cost marketing isn’t bringing people in, you’re stuck.  Buying a product audience is not a fast-fail means to reducing risk.
4. The alternatives to your product are substantially cheaper/easier/more well-known. Every product has an alternative, even if the alternative is “do nothing”.  Even if customers agree that your product is objectively better than the alternative(s), there is friction involved in them spending more money, spending more time, or even just choosing a different brand than what their friends are using.
5. You’re competing against entrenched competitors who are better-funded/more well-known/have substantial market share. This means you can’t compete with them on their terms – you’ll need to try something different to create a Blue Ocean for your product.

If any of these are true, it’s time to stop, re-evaluate your market and your customer’s needs, and look for the next experiment – as quickly as possible.  Continuing to improve upon your product may get you incremental gains but at a time, opportunity, and funding cost you can’t afford.

Have you experienced any other sure signs that it’s time to change your product strategy? Please share with us in the comments.

This post is Part 1 in a series.  Read Part 2.

The blunter way of putting it is, no one cares about your great ideas. Because as long as they just sit there, good ideas aren’t any better than bad ideas or silly ideas or ridiculous ideas or insulting ideas.

Free Ideas. Just Add Execution. (Laserlike)

Share your ideas. Doing so will make you feel like you need to go do them, because of the small risk that someone will take your idea now that it’s “out there” and beat you to it. Sharing your idea will expose you to diverse feedback on it. Your idea will get pressure tested.

I’d add to this: if you don’t have any already, find some friends who will hold you responsible for following up on your idea. If you really believe an idea is great, you owe it to yourself to make an investment in it. That may be money, but more often than not it’s just time, research, and a commitment to keep questioning. Figure out what kind of experiment you’d need to run to get a better sense of the idea’s future success or failure. Then do it.

Be that friend: hold other people responsible for their ideas. At dinner a couple weeks ago, a friend of mine mentioned a potential new concept for his business. We discussed it for a while and asked some questions and encouraged him to think more about it – “at least grab the domain name,” I said. He promised he would.

A week later, I went to Discount Domain Registry to check up on him and make sure he’d followed through. (He did.) And guess what? Now I will totally feel like a hypocrite if I don’t follow up on my own projects. It’s a win-win situation.

Your Idea Alone Has No Value (Will Shroter)

It’s not uncommon for a startup company to go toe-to-toe with a much larger company offering a very similar product. On its face, it looks like the startup is at a severe disadvantage…If you were to try to compete against the behemoth on their own terms you’d get crushed. That’s why startups tend to look for the weak spots in larger companies and exploit them.

Look for the unfair advantage. It’s not just for making a business case, but for any situation. What do you uniquely know or what are you uniquely skilled at?

When I started working for a financial software company, I was at a distinct disadvantage in domain expertise. Aside from reading Motley Fool and watching CNBC, I didn’t have a lot of knowledge about the various banking industry players or their customers. But I am good at at-libbing. So I’d open up a product demo with “I’m going to walk through our product from the perspective of a customer – help me out as I go by telling me about your customer.” I’d adapt the story as I got feedback instead of pretending to be an expert.

(I remember vividly presenting to a group of wealth management executives, who pointed out that my sample data had far too few zeroes to represent their audience. “Your customers?” I asked, “Uh-oh, this must be the version of the demo based on my net worth. But the beauty of the product is, it works for me, and it’ll still work for me in a couple decades when I’ve made it to being one of your customers.” They laughed – I breathed a sigh of relief.)

Entrepreneurial Proverbs (O’Reilly Radar)

Sometimes an idea catches hold of you and you find you can’t put it down. Pay attention to that! Just start working on it. Can’t get yourself to do anything on it? Move on.

…Entrepreneurs too often worry about keeping their brilliant secrets locked away; we should all worry much more about springing a surprise on a disinterested market (anyone remember the Segway?)