Login

The Evolution Of The Customer Development Interview

Back when I did my very first customer development interviews, way back in 2007 for an aborted Slacker-player-over-cellular-networks company, they were called "requirements gathering".  Go out, get a big list of requirements, write a product spec, release, and bask in your glory.  Pretty simple.  

Needless to say, my approach and techniques since those halycon days has changed a lot.  Now I believe that users have no idea about solutions; they only know about their problems.  

Inspired by Cindy Alvarez's (@cindyalvarez) post, here's a real-world list of questions I recently asked a number of potential oneforty users and my thinking behind each question:

1) How/why do you use Twitter? (Make sure to push on business/personal use to understand both)
2) Tell me more about what you think Twitter is (For others in your industry / average users).
3) How has your use of Twitter evolved?  Are there any particular things about Twitter that suck?
4) Do you use any tools for Twitter or other social networks?  (Note that I don't ask where they find Twitter tools; I don't want to assume that they go looking at all.) 
5) What sorts of Twitter tools would be so useful that you'd be willing to pay personal money for?  (The personal use question - do they *really* want/need Twitter tools?  Consider it a pre-emptive "how disappointed" Sean Ellis question.  If the answer is "none", it's the equivalent of a less than 40% "very disappointed" response.)
6) What sorts of tools would you be willing to spend your employer's money on?  What is your budget?  Do you need a Purchase Order or approval above a certain threshold?  (Pricing discovery to gather lower stakes information about willingness to pay - with OPM.)

One of the things that you'll note is that there are only six questions.  These are the six questions I want to get answers to; they don't have to come in this order, but I want to try to get to them.  They serve as jumping off points for each stage of the interview, not the next step.  If the interviewee goes off on a tangent, it is my job to follow her there.  I can cut her off if and only if we're running short on time.  If time's not a worry, exhaust the tangent, then and only then move on to the next kickoff question.

With these kickoff questions, I start as far back as I can so I don't assume that the problem I'm trying to solve is actually a problem for my user base.  Even if I've done previous interviews and come to a pretty firm problem statement, I always start from the beginning to try to get the user to come to that same problem statement organically.  If the user doesn't come to that statement, I abort the script and dive into the problem.  

I also never, ever suggest or test potential solutions during customer development interviews.  Once upon a time, I did.  I would suggest a number of potential solutions to my interviewees and ask them to rate or rank them.  Turns out they always chose the solution I secretly liked the best.  What a coincidence, that.  It almost convinced me that I could skip the whole discovery process because my market research (read: Googling) was so good.  

Maybe I'm not as good as others who conduct these sessions, but I had a hard time shielding my biases when talking about solutions with interviewees.  Users don't know what solution is best until they actually use it - they only know their problems.  So I stopped polling potential solutions and now I rely on interaction data and metrics by actual users of the actual product or MVP. 

Again, my magic phrase in every customer development interview is "that's interesting - tell me more."  (Note: this also works great on dates.)  Also, I never ask a yes/no question, I let pregnant pauses hang in the air until they're almost awkward, and sometimes I'll even willfully mischaracterize a interviewee's opinion to elicit their response - all in hopes of getting the interviewees to keep talking so I can get every last insight from the brief 30-60 minutes I have with them.

Hopefully, seeing a real, live customer development script used by a real startup with real potential users has been useful.  Fire away in the comments if you have any questions, concerns, or suggestions on possible new approaches.
Tags
1 response   //   Posted about 3 years ago

On Incorporation - I Still Say Hold Off Until You Have The Cash To Spare

In my last post about startup cash management, smart people like Chris Dixon, Manu Kumar, George Grellas, and the Hacker News cabal all disagreed with my advice to put off incorporation until you absolutely have to. 

Every single benefit of incorporation cited by these people is correct.  However, I still caution against jumping right into incorporating from day one.  This is because when you incorporate, you should do it right and doing it right isn't a drop in the bucket.  Also, when you incorporate, you're subject to your state and federal taxes, Delaware franchise tax, foreign business license in the state where you're headquartered, and other administrivia hassles.  But keeping in line with the last post, I'll stick to the cash.

When I founded Dawdle, I engaged a local Chicago law firm that was well-regarded in the startup community to do a simple incorporation.  It ran us about $1,500.  I didn't want to use LegalZoom to do the simple incorporation because I wanted to develop a relationship with my lawyer that I could leverage to make introductions to local potential investors when the time was right.  

However, soon after incorporation, I realized we needed an option plan for a potential employee we were recruiting.  Because my lawyer had set us up as a subchapter-S Corporation, he was unfamiliar with how an option plan should be structured for an S-Corp and ended up having to do substantial research to get it done.  The option plan ended up costing us an additional $6,000.  There are additional pieces of advice that we got that was incorrect, the sum total of which ended up costing the company over $40,000 in additional, unnecessary legal expenses (hindsight is 20/20).

Based on this experience, I strongly believe that any company that may potentially seek institutional money should use a top-tier Silicon Valley partner at a top firm.  It doesn't matter where your company is; get a Valley partner.  Many of these top tier firms have "off the shelf" packages that include much more than incorporation - some include the option plan, convertible note template, NDA form, and other commonly used documents.  You can see a sample of the bare minimum set of incorporation documents at TheFunded.  If you hold off on incorporating yourself and you get into a top-tier accelerator such as YCombinator or TechStars, they will also incorporate the company, with the whole kit and kaboodle, for you.  YC even tells potential applicants to not incorporate "if you can avoid it".  You probably can avoid it.

If you aren't going the accelerator route, and you've decided the time is right to incorporate, you'll need to get a full incorporation package from one of these firms.  This package runs approximately $5,000 or so from a top-tier firm.  (Feel free to let me know if this has gone up since the last time I checked.)  Generally, a paralegal will just fill in the blanks and the partner you choose will do a cursory glance, but the partner is 1) the person who can answer your questions without any research, saving you money and 2) the person who will be making introductions to potential investors.  It's important to pick your partner carefully.  Thankfully, my ex-Broadview colleague Giff Constable has a great list of lawyers that do good work with internet startups.  If you want specific thoughts on how to pick a startup lawyer, read Mark Suster's post on the topic (even though he's in the "incorporate yesterday" camp, it's still a great post).  

My personal recommendation for startup incorporation and general corporate work is Yokum Taku of Wilson Sonsini.  In addition to being wicked smart and a straight shooter, Yokum's blog, Startup Company Lawyer, probably already answers the first five questions on the tip of your tongue.  Past that, any answer to something you can't find on the blog is going to be consistent with what he's already written, saving you from conflicting advice.  You can read my rambling notes from my conversation with Yokum about incorporation at my personal blog.

I also don't believe that you should take advantage of deferred legal fee loan programs offered by some Valley firms because you're locked into working with that firm until you've closed your Series A.  If the partner leaves, the firm overbills against the deferred fee loan amount (usually $25,000), or the relationship doesn't work out for some other reason, you don't want to be stuck.

Because "doing incorporation right" is a rather large expense, I don't believe that entrepreneurs should incorporate until they are playing with other people's money.  Solo entrepreneurs need to watch every dime and I firmly believe that small founding teams can set the parameters on a napkin when starting out, to be codified when the time demands it.  If you can't trust your co-founders to stick to a terms written on a napkin, you've got bigger problems to tackle.  Sure, all else being equal, you do want to incorporate as soon as you can to start the capital gains clock, minimize the value of founder shares, and all the other benefits or early incorporation.  But $5,000 is still $5,000 and cash is king.

 

Tags
11 responses   //   Posted over 3 years ago

Three Things To Put Off As Long As Possible For Your Startup

While there are often investments that should be made upfront, oftentimes new founders and new startups will waste money and time on things that they shouldn't.  I sure know I did during my first go-round.  Don't make my mistakes.  Here are three things you should put off as long as possible:

Don't incorporate until you're playing with Other People's Money.

There are two kinds of other people's money.  The first is Other People's Money - investment dollars from outside sources: friends, family, angels, VCs, certain grants, and so forth.  The second kind of other people's money is even more important - paying customers.  Any concern about your personal liability is misplaced; if your site has a bunch of Google AdSense ads, no one in their right mind is going to sue you.  You're going to need to be incorporated to deposit any investment (if you're so lucky) and you'll need to be incorporated to get an internet merchant account.  You can probably get by with a PayPal account (under the domain of the site; don't use your personal PayPal account) for a while, as well.  And don't worry about the intellectual property you create before incorporation; you can always assign it to the company later.  That's what Google did when they got their first check before they were even incorporated.  

Don't do any paid user acquisition until you can calculate your CAC and LTV.

It's very, very tempting to "experiment" and "test" various paid customer acquisition channels.  You start with AdWords, then do some cheapo banner ads on a couple of ad networks, and soon you're hooked on some hard affiliate stuff and paying thousands of dollars a month to an Outsourced Program Manager.  AdWords are a gateway drug to unprofitable user acquisition.  Only start throwing your dimes at paid acquisition when you're damn well sure your dimes-into-dollars machine is humming nicely.  And you only really know it's humming nicely until you have enough metrics around your unit economics - what your costs are to serve every new customer, and how much she's worth to you in revenue (if you're rigorous, gross profit).  These numbers have to come from real users using your real product; they cannot come from a financial model - that's just guessing.  Get hard data.  Then and only then can you think about customer acquisition channels that have direct costs above zero.  Until then, you're much better off engaging in inbound marketing - making remarkable content (you blog regularly, right?) and a remarkable product - and really thinking about your on-site SEO.  

Don't hire a PR agency, part-time sales force, or any other outside consultant.

You want to be focused on the product.  You get the market well from your industry background and you know you have your problem statement nailed from your in-depth customer development interviews.  You need to focus on building your product solution hypothesis and you just can't be bothered to do the legwork of developing relationships with bloggers, press, potential customers that you don't know, or potential business development partners.  You met some smooth business guy at some tech meetup who says he can do all this for you for a small amount of cash and equity.  Seems like a good deal, but it's not.  Managing someone who isn't a full-time employee and who isn't as invested in the company's success as you are is a path towards hurt feelings and wasted time, energy, and cash.  There are certainly times and places for help in all these matters, but pre-launch isn't it.  (The only exception is if you've raised millions of dollars in Other People's Money and you can afford to pivot your product, positioning, and or price if your big splash fails.)  You probably won't be as good as someone whose work life is dedicated to press, PR, sales, marketing, or whatever - but you're going to be a lot cheaper and you may not be all that bad at it yourself.  A passionate and articulate founder can go a long way - I was able to do all of this myself, getting into TechCrunch, landing new customers from cold-calling, and striking business development deals.  You can too.
Tags
30 responses   //   Posted over 3 years ago

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.

Tags
2 responses   //   Posted over 3 years 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.

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).
Tags
2 responses   //   Posted over 3 years ago

New Blog: Meat In The Sky

I've started blogging about startup life, with some thoughts and actionable startup advice for founders and early employees at http://blog.meatinthesky.com.  I'll be focusing on the stuff before product/market fit.  This is the period of the most experimentation and the lowest burn you can do - it's the most perilous part of the startup process, as you're walking a tightrope without a net.

As for the name, see the first post.

And you can follow @meatinthesky on Twitter to be notified of new posts.

1 response   //   Posted over 3 years 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.
Tags
0 responses   //   Posted over 3 years 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.
Tags
1 response   //   Posted over 3 years ago

Bring Back The Evening Paper!

Commodity national news is dead.  Newspapers are dying.  The AP wire on Yahoo News (or Google's more heterogenous and more cluttered version) and CNN.com are "good enough" that all other services providing "just the facts, ma'am" provide no incremental value.  Most observers recognize that this leaves a void in the local space, and predictably you see newspapers retrenching into their neighborhoods, fending off competitors like Outside.in, EveryBlock, and ESPN's local sites.

But newspapers have so much more than just news, and that's why I love to read them when I visit my family in St. Louis.  I find value from the comics, the circulars, the coupons, the crossword, and, yes, the columns.

But why do I only read the paper when I'm visiting my mom and grandparents?  Why, the NYT and Tribune executives plaintively scream, why oh why don't I subscribe where I live?  

My biggest issue is delivery.  At my former apartment in Chicago's Logan Square, I had no faith that any paper I paid for would still my at my apartment building's doorway when I woke up in the morning.  I even subscribed to the free Saturday Redeye and it never showed up.  My new apartment is one of those old houses in a better neighborhood near Somerville's Davis Square, and I'm considering getting the Sunday Globe and/or Times.  But only on Sundays.

But here's the other delivery problem beyond just getting what I paid for: when the paper comes in the morning, I don't have time to read it.  When it comes in the morning, half of it is stale the minute it hits the stoop because I read that information online the previous day and the other half is stale by the time I do have time in the evening.  It's completely useless to me (again, except on the weekends, where my mornings are leisurely and my evenings are packed).

But this can be solved with a change to the content and a switch in delivery time.  An evening paper that focused on analysis and columns, rather than the stenography that passes for reporting, would be fantastic.  I could indulge with 15-20 minutes attempting the crossword; I could read the comics over a cup of tea (or a glass of bourbon or whatever your racially- and temporally-appropriate stereotype is); and I could browse through columns and analysis of new and interesting topics that aren't top of mind during the workday.  

Giving up all pretense of presenting the bare facts of news would free an evening newspaper from the tyranny of the mid-day deadline.  An evening paper as I envision it wouldn't compete with the evening news hosted by Brian Williams, Katie Couric, or Diane Sawyer.  It wouldn't compete for the advertising dollars of incontinence products and life insurance.  It would be more alive and it would be a better vehicle for television, movie, and other entertainment advertising than the morning paper or the evening news.  

A new evening paper would require shunting aside any pretense of being balanced in favor of presenting a wide range of opinions (I think the Atlantic does the best job of this on the national blogging/magazine side), but it could easily be done given the newspaper companies' existing delivery infrastructures and brands.  

And that's the way it is.

One related note, since this is being passed around this morning: I don't in any way believe we are nearing the end of hand-crafted content.  Just read Ezra Klein, Matt Yglesias, Felix Salmon, Ta-Nehisi Coates, or any of the other brilliant writers who pump out fantastic free content with real, actual reporting on a near-daily basis, and you'll realize that at the national level, there's a plethora of great, handcrafted content.  (BTW, are there any female writers - aside from Digby - who I should be subscribing to?  Megan McArdle lost me a while ago.)

Maybe it's different if you're checking TechMeme every 15 minutes to see who gets "credit" for "breaking" some "story" about some "gadget", but the stuff that I read is great.  Hell, just follow Paul Kedrosky; it's like the dude was put on this earth to create and share interesting shit that's perfectly up my wheelhouse.
7 responses   //   Posted over 3 years 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.
2 responses   //   Posted over 3 years ago