Meat In The Sky Blog

The Other Stuff That's Not Product That You Need To Build Early

One of the things that I didn't think about before I started my first startup were all the parts of the infrastructure that weren't product. They've also consistently been the things that other entrepreneurs forget about when they come to me with their "ohmygodIhavethisidea" ideas. They're also vitally important because they allow the founding team to actually execute the pivots you'll need to execute quickly, intelligently, and without sacrificing development of the actual product that you're trying to pivot.

The first part of this infrastructure is the admin panel. This admin panel is what will allow you to do troubleshoot for customer support, engage in administrative actions, and audit your payments in and out of your system without having to mess around with your production database. I cannot impress upon the first-time web entrepreneur just how important it is to have a robust and well-functioning administration system. When you're building your administration system, it is important to make sure that you can disable and delete users, view and change payment regimes, and reset user passwords (because they will invariably not be able to find your reset password form and they *will* e-mail you). If your product takes off and you find yourself bringing on board a business person, they're going to be tasked with support, and you do not want whoever is doing support interrupting engineering to complete basic Level 1 and 2 customer support. If your product really takes off, you may find yourself bringing on board a dedicated support person. If you wait until traction to build out your administration panel, you're going to be ceding ground to the competitors that spring up when they see your traction. Django's admin panel is so well developed that you may not have to build your own, and is a reason to strongly consider the framework if you're familiar with (or interested in) Python. Even as your product pivots, the administrative support tasks generally don't.

Make sure you've built a functional admin panel before you launch.

The second part of the infrastructure you're going to want to build (or implement with WordPress, Melody, or some simple bare-bones CMS plugin that someone has already released for your framework) is a content management system (CMS). It should not take a push of new code to change the static content on your website. Holding up basic changes and updates to your about section, marketing pages, terms of service, privacy policy, and help section because you need to wait on some guy to merge his branch into master (or check into trunk, or whatever your VCS calls it) is silly. You don't want to have your marketing person or intern create some hot new copy then have to hand it off to engineering to copy/paste it into code and markup each and every link, line break, and image to get it live on the site. It makes the business side frustrated with the pace of changes and the engineering side of the house gets frustrated at having to do such menial tasks when they could be building some crazy awesome technology that is your core long-term competitive advantage that you brought them on board to do. Again, some web frameworks have bare-bones CMSs or templating engines built into the system out of the box.

Make sure you've built (or implemented) a content management system before you launch.

The third part of the infrastructure you need to build is a good metrics dashboard and logger. The standard piece of advice is "pick a few metrics, but log everything". The idea of logging everything when you've decided to focus on just a few Key Performance Indicators (KPIs) can often cause heartburn. But it's relatively simple; build a separate table (or database) that automatically logs all the various things that users do. Don't worry about duplicating writes that you're doing elsewhere in your database. Having a separate table (or better, database) will save ou on reads and JOINs and whatever else when you need to dig in. The one thing the logger needs to do is be *auditable* - that is, you need to be able to say that user_id=8273 did x on page one, then y on page two, then z on page three. These loggers are so important that there are venture-backed startups that exist solely to help other startups collect these logs and make sense of the data they're collecting. The KPIs are, of course, actionable metrics that exist in the aggregate, but the ability to see what any individual user has done will help you troubleshoot, audit, and make hypotheses for new features and functions. Also, one quick note: Google Analytics aren't auditable at the user level nor actionable in helping you make forward-looking hypotheses. Everything in Google Analytics is backwards looking. The product is free as in beer and all-but-free from an engineering cost perspective, which is great. GA does give you the ability to find exception cases and the basic funnel visualizations can be useful for getting conversion metrics up and running quickly, but don't kid yourself - Google Analytics is mostly data porn.

Make sure you build a real metrics dashboard and implement a real logger before you launch.

Loading mentions Retweet

Filed under // leanstartup

Comments (2)

Posted 7 days ago

Product Development Starts With A Hypothesis, Not A List Of Requirements

For a startup to be successful, the founders (or whoever owns product) need to have strong opinions about both the market problem and the product solution. Sometimes - maybe even often - this means ignoring your users.

That doesn't mean that you don't listen to your users - even companies as insular as Apple and Nintendo do some work reaching out to others. Apple designs for others; they just don't do formal market research. Nintendo has "random employee kidnappings". But if you don't have the luxury of having the singular, strong editorial voice that Apple gets from Steve Jobs or that Nintendo gets from Shigeru Miyamoto (or that 37signals gets from Jason Fried), you probably have to set yourself up to conduct lots of experiments.

Do you remember your scientific method? If not, here's a really, really good primer on the scientific method. Never mind that it's written for children - it's good. Here are the steps:

Ask a Question

Do Background Research

Construct a Hypothesis

Test Your Hypothesis by Doing an Experiment

Analyze Your Data and Draw a Conclusion

Communicate Your Results

If you've noticed, we've actually done the first two steps. Asking a question is finding a market you're interested in. Doing the background research is figuring out the problem statement. The next step, where we are now, is to construct a product hypothesis. Remember, when you test hypotheses, they're falsifiable - you only can find out what *doesn't* work for sure.

Below is a great slide by the guys at Watching Websites:

What this means is that you have to keep pivoting until you find yourself in product/market balance. Too bad that every product hypthosis and every pivot costs you in time, money, blood, sweat, tears, and all the other various inputs. You can't iterate forever; you're going to run out of one of those inputs (most likely money).

The only way to reduce your time in this cycle is to make a really good hypothesis from the get-go. If you're not playing with other people's money, then you better make sure that you don't have to pivot at all.

Listen to your users on the problem statement - they can feel that pain. But listen to your judgment on the first product hypothesis - there's a reason you want to solve this problem, and it's not because you're a stenographer. It's because you see something everyone else doesn't. Asking better questions allows to more clearly see what others - even your users - may not. Here are some better questions to ask:

Are your customers time poor or just frustrated with the time they have to spend on a task?
Are your customers cash poor or not seeing value for their money?
Are your customers status poor or are they embarrassed to use your product?

Customers often will tell you one answer, but they often mean another. It's your job to 1) ask better questions, 2) read between the lines of the answers, and 3) use your judgment to make a really good product hypothesis.

Dropbox doesn't save a large amount of time; but it makes saving/retrieving files thoughtless. RC Cola just didn't have the status of Coke (or Pepsi); you can always get store brand pop if cash is king.

If you better understand the true pain, you'll make a better product hypothesis. Dropbox is great because it "just works", but it took Drew to define what "just works" meant above and beyond Mozy, Carbonite, XDrive, and every other storage in the cloud provider. RC Cola "tasted better" (they won every blind taste test they sponsored, supposedly), but it turned out that people didn't pick their pop based on taste. They picked it based on status, nostalgia, inertia, (and as the supermarkets found out) price as a tiebreaker between Coke and Pepsi. Remember, your users may lie to you.

Users may not know what they want in a product until you show them. But they always - always - know their problem.

(That's what Steve Jobs is so damn good at. He keeps using Apple's prototypes until the stabbing pain of the problem Apple's identified goes away. Then and only then does he bless a new device/program/feature. See copy/paste on the iPhone.)

Your judgment on how to solve the (real, maybe unstated) problem of your potential customers is your initial competitive advantage. Your ability to get a product hypothesis out there that your users don't immediately reject (and hopefully would be terribly disappointed if you took it away) is what gets you paid the big bucks (when you exit).

Loading mentions Retweet

Filed under // leanstartup

Comments (0)

Posted 14 days ago

Because You Hate Your Family, or, Stuff To Read Over The Holidays

Let's face it - you love your family, but that's today, before you see them. By Boxing Day, you're going to want to curl up in the fetal position as your uncle yammers on about the Cleveland Browns. As long as you're hiding out in the basement, or drinking alone at the depressing corner bar, you might as well do something productive. Here's a special "must read" list of books, blogs, and presentations while you stew about in the hellhole your parents call home.

Steve Blank - the granddaddy of them all. Steve coined the term "customer development" as a parallel process to product development. Steve's blog is fascinating (the man has done some very interesting stuff), but the must-read is his book, Four Steps to the Epiphany. In particular, it specifically talks about how to work when you're disrupting an existing market versus when you're building a new market for your product. You have to read Four Steps first.

Eric Ries - the new hotness. Eric took Steve Blank's class, learned about customer development and had the insight to pair the customer development process with extreme programming to create a continuous improvement/feedback loop. Eric coined this process "Lean Startup". Eric's blog is great, but he has a MVP beta of his posts in an e-book, which may be easier to read. You should buy it now, since Lulu might take a while to ship.

Dave McClure - the pirate. Dave's AARRR model is the best compilation of every driver you need to measure. You can't just slap on Google Analytics and think you're done, folks. He's kind enough to post new versions of his Startup Metrics for Pirates presentation as he revises it (video of an older presentation), but Dave's blog (while a bit all over the place) is chock-full of great insights.

Sean Ellis - the Glengarry leads guy. You've built it; now what? Sean only works with companies that have raised venture money and already achieved product/market balance (see why I don't call it product/market fit). You don't even have a product yet. Why is he a must read? Because his approach to measuring product/market balance is better than anyone else's. His startup pyramid tells you each necessary step before you can turn on the growth spigot. Sean's blog is updated less frequently, but every post is great.

Andrew Chen - the savant. Andrew's spent a lot of time thinking about viral loops. Virality isn't something that just happens to great products - although that does happen from time to time - virality is something that can be baked into your product's DNA. Andrew's blog is full of posts that go into viral loops in detail, and it's much easier to read now that he made a special categorized list of posts for you. You can't possibly read all of this before you come home, so I'll stop there.

Loading mentions Retweet

Filed under // leanstartup

Comments (0)

Posted 1 month ago

Requirements Gathering Is Not Customer Development - But It Does Define The Problem Statement

Customer development is all about testing your hypotheses. This is the Lean Startup diagram by Eric Ries that you (should have) seen before:

Let's start at the beginning and focus on the Customer Development Process, and in particular, the Customer Discovery loop at the very beginning:

Steve Blank has defined the Customer Discovery loop as four parts: Author creates Hypotheses; Author Tests Problem Hypothosis; Author Tests Product Hypothesis; and Verify, Iterate, and Expand (slide 11):

The problem that I've seen time and again is that people fall in love with the process and get so caught up in the notion that they can just iterate through their hypotheses that they create terrible hypotheses.

This is dumb.

People - especially smart people - love the idealized notion of "iteration" but, in practice, it turns into "throw shit against the wall and see what sticks". Then they realize the hypothesis testing iteration process takes time and soon, they start to believe they're making progress merely because time has progressed. Then they start product development too early. Then they... well, you can guess what happens from there. Don't do that. Spend just a bit more time up front. Understand the problem you're solving first, so you can make better product hypotheses from the get-go.

Simplify the Customer Discovery loop into two parts: requirements gathering to define the problem statement, and hypothesis creation that you test with actual potential customers in the Customer Validation step. Here's the difference between me and Steve: you don't iterate on the problem hypothesis - the problem statement is a fact that you have to suss out from your requirements gathering. Your job is to suss out 1) whether or not there is a problem, 2) how big of a problem it is, and 3) how big the market is that's affected by the problem. (You don't want to develop a product to solve a problem that won't return your investment of time and money. This is the result of jumping into the "test product hypotheses" too early.) These are all verifiable facts; the problem statement is not a hypothesis. Anyone else going out to the same customer base and asking the same questions will come up with the same problem statement that you do.

Defining a problem statement really isn't all that hard. Sure, you can read research reports and get market sizes and all that jazz, but the one prerequisite you must do is really quite simple: talk to enough potential customers until you've reached some point of diminishing returns. (You'll know it when you get there.) Often, this doesn't take more than a dozen. If you really want to be rigorous and pretend you've gotten to statistical significance, talk to 30 people. Here's a simple list of questions:

* How do you do [x]?

* What's the worst thing about doing [x]?

* How much extra time/money/energy does it take to deal with the worst thing about [x]?

* If I could solve the worst thing about [x], how much money would you pay me? (Note that if it costs money to deal with the worst thing about [x], theoretically you could charge up to 99.9999% of that amount. Theoretically.)

Everything else is optional. My trick is to keep them talking with one simple phrase: "that's really interesting. Tell me more." You may even (read: you will) get product insights from your problem statement questions.

Eventually, you should be able to hone in on what exactly is the jabbing pain in your customers' eyes. For salespeople, it was that they had to input all their information into ACT and then do extra work when they got to the office to share it with their manager (Salesforce.com). For runners, it was that the shoes they had weren't really comfortable for running long distances (Nike).

The iteration comes only with the product hypotheses - and I use the plural because you want to consider all the different product approaches that can solve the problem.

Let me finish with this: you don't define the Minimum Viable Product. The market does. At the beginning, your job is to form good product hypotheses that you test. These product hypotheses spring forth from spending the time in requirements gathering to sharply define the problem statement that you are going to solve with whatever your product solution ends up being.

If you've done the work to define a robust and accurate problem statement as a result of a rigorous requirements gathering process, you'll receive much better market feedback when testing your product hypotheses. Eventually, when you start market testing your alpha product, you'll have a much shorter process getting those orders/eyeballs/whatever to determine you've hit your MVP.

Next time, I'll talk about when to follow and when to ignore your customers when defining and testing your product hypotheses.

Loading mentions Retweet

Filed under // leanstartup

Comments (0)

Posted 1 month ago

Forget Product/Market Fit; It's All About Product/Market Balance

In my time watching and working with startups as an investment banker, VC, entrepreneur, and consultant to startup teams, the notion of product/market fit has gone from a new insight to conventional wisdom.

However, product/market fit never seemed like the right notion to me.

After doing some thinking and working very closely with a handful of startup teams in the last year or so, I realized that a team isn't looking for product/market fit; it's looking for product/market balance. The notion of balance highlights the delicate task of getting a product to meet a market's needs:

Even if a team builds a robust, stable product offering, the product can fail to meet the market's needs and the product lands with a thud:

The notion of balance serves another purpose; balance provides a basis to extend the metaphor into the other important parts of a product experience: positioning and pricing. Here, you can see how the product supports positioning:

Likewise, the product + the positioning supports the price structure:

If the product itself balances with the market's needs, poor positioning can upset the balance and lead to everything tumbling down:

And a poor price structure can lead to defeat even with the right product and positioning strategy:

You can't decide to position a product as premium if the product is shoddy. Likewise, the price you choose reinforces and strengthens your positioning - you can't have a "value" product that is priced higher than your competition.

Startup teams must make sure that everything about their product, positioning, and price structure maintains the delicate balance necessary for market success.

Loading mentions Retweet

Comment (1)

Posted 2 months ago