earthy!

Since I’ve been working on Google Reader, I’ve told a lot of my friends about how great it is. And while some of them try Reader and find it really useful, many of them aren’t interested in taking the time to get Reader set up. That’s why today, I’m happy to announce an experimental product from the Google Reader team that makes the best stuff in Reader more accessible for everyone, while giving Reader users a new way to view their feeds. It’s called Google Reader Play, and it’s a new way to browse interesting stuff on the web that’s easy to use and personalized to the things you like. Best of all, there’s no set-up required: visit google.com/reader/play to give it a try.

In Google Reader Play, items are presented one at a time, and each item is big and full-screen. After you’ve read an item, just click the next arrow to move to the next one, or click any item on the filmstrip below to fast-forward. Of course, you can click the title or image of any item to go to the original version. And since so much of the good stuff online is visual, we automatically enlarge images and auto-play videos full-screen.

Reader Play adapts to your tastes — as you browse, you can let us know which stuff you enjoy by clicking the “like” button, and we’ll use that info to show you more items we think you’ll like. If you want, you can also choose categories, and we’ll personalize your stream to only show you stuff from those categories. And you don’t even need a Google account to use Reader Play. Of course, if you want to star, like, or share items, we’ll ask you to sign in to your Google account. Since Reader and Reader Play share the same infrastructure, any actions you take in one will be reflected in the other.

You might be wondering where we find all the awesome stuff in Reader Play. It uses the same technology as the Recommended Items feed in Reader to identify and aggregate the most interesting items on the web. If you sign in, Reader Play will also be personalized with items that people you’re following have shared in Google Reader, and items similar to ones you’ve previously liked, starred, or shared.

Since Reader Play is an experiment, it’s launching in Google Labs for now. To be clear, Reader Play isn’t intended to replace Google Reader: both Google Reader and Reader Play are about finding and reading interesting stuff online. In essense, Reader Play is a different view of Reader. It’s designed to be a fun and easy way to browse interesting items, while Reader is a highly customizable way to organize your feeds, keep track of what you’ve read, and much more. In Reader, you can switch to this view by clicking “View in Reader Play” from the feed settings menu.

Try Reader Play today and let us know what you think. Send us feedback in our forum or on Twitter, and check out our help article for more info.

I have been trying this out for a bit, pretty cool, remind me of Redux and how they do full screen video where you can cycle through all the posts

Together with Raj Menon and Francis Martens I’ve been preparing a new launch of the Management 3.0 site. Raj has been working on the lay-out, and Francis and I have been working on the queue of blog posts. Starting tomorrow we will publish guest posts from (and for) anyone interested in agile management.

We have a couple of well-known authors in our queue. But we also appreciate fresh and interesting posts from unknown authors. No matter if you’re writing for the very first time, we welcome your thoughts on (and your experiences with) management in an agile organization.

You can find some help and guidelines here. And you can submit your posts here.

(image by Matthew Simantov)

Tags:

Share Twitter Facebook

• < Previous Post
• Next Post >

Issue 68 – 01 | Rework: A Better, Easier Way To Succeed In Business
By Jason Fried & David Heinemeier Hansson Published March 3, 2010 12:00 p.m.

“In the real world, you can%u02BCt have over a dozen employees spread out across eight different cities over two continents. In the real world, you can%u02BCt attract millions of customers without any salespeople or advertising. In the real world, you can%u02BCt reveal your formula for success to the rest of the world. But we%u02BCve done all those things and prospered. The real world isn’t a place, it%u02BCs an excuse. It%u02BCs a justification for not trying. It has nothing to do with you.”

View this manifesto | Download as PDF | 2 Comments and 54 Reactions

About Jason Fried & David Heinemeier Hansson | Jason Fried and David Heinemeier Hansson are the founders of 37signals%u2014a trailblazing software company that produces products used by millions of people around the world. They have been profiled in publications like Time, Newsweek, and Wired. They%u2019re also contributors to Signal vs. Noise, on the Web%u2019s most popular blogs. To learn more about Rework and 37signals, go to 37signals.com.

http://37signals.com/

blog comments powered by Disqus

Issue 68 – 05 | Is Your Product Launch Doomed?: 10 Ways to Identify an Impending Launch Disaster
By Dave Daniels Published March 3, 2010 12:00 p.m.

“Products don’t sell themselves.

The process of introducing a product to market is a serious undertaking. Unfortunately for many companies it%u2019s merely an afterthought; a set of deliverables created from a checklist at the end of product development. When the level of effort and resources applied to the creation of the product dwarfs that of the launch, it%u2019s no wonder product launches fail to achieve the sales velocity anticipated.

What follows are ten easily identifiable signs that help forecast if a product launch may be in trouble. Signs you can address and fix before the launch becomes a disaster.”

View this manifesto | Download as PDF | 0 Comments and 8 Reactions

About Dave Daniels | Dave Daniels is an instructor for Pragmatic Marketing with more than 25 years of experience. He specializes in product marketing and product launch, with an emphasis on effective go-to-market strategies and execution. His extensive background includes development, sales, product management and product marketing, with a global perspective of the entire product launch process. Prior to joining Pragmatic Marketing, Dave founded Launch Clinic, a consulting company focused on helping organizations implement successful launch strategies. He speaks at many industry events about launch best practices and writes the Launch Clinic blog.

http://pragmaticmarketing.typepad.com/lau

blog comments powered by Disqus

Last year, Steve Blank threw out a challenge to Lean Startup Circle members to update his customer development checklist (Appendix B in his book) for their specific business. His checklist is built for Enterprise Software which doesn%u2019t readily translate to other types of startups including web startups (especially when you get to Customer Validation).

After the talk, David Binetti pulled together a great group of people from Lean Startup Circle to create a Customer Development Checklist for web startups. I was honored to be asked. However, after a few exchanges trying to nail down the type of web startup to tackle first, we uncovered a number of tactical differences that made me come to the realization that defining such a model in a group setting is too hard to do. We would either end up with a highly generalized model or no model. I, for one, am not comfortable extrapolating a model from third-party accounts of what might have worked for other companies (like 37signals), and especially not without first-hand experience building a similar type of startup.

So I decided to take a stab at defining a Customer Development Checklist for my web startup.

First Some Background

This model is based on my experiences building and running 2 products: BoxCloud and CloudFire. Both use a subscription pricing model. BoxCloud was built using a release-early release-often development model and was initially launched with a Freemium pricing model %u2013 later changed to a free-trial only model. CloudFire is being built using a lean-startup/customer development model and was launched with a free-trial only model.

For a SaaS product like mine, I strongly believe you need to
a) charge for your service, and
b) validate pricing sooner rather than later.

Free trials, Freemium, free introductory periods, etc. are all tactics to lower sign-up friction and should be applied (split-tested) judiciously on a case-by-case basis. However, my key takeaway is that even if you%u2019re considering Freemium, you should validate the premium part of Freemium first before giving anything away.

I%u2019ll cover Customer Discovery in Part 1 and Customer Validation in Part 2. Hopefully, I%u2019ll get to write Parts 3 and 4 one day.

Customer Discovery: What should I build and for whom?

Here%u2019s my Customer Discovery Flow (you%u2019ll probably want to click to enlarge and skim it before reading on).

Click to Enlarge

The 3,000 Foot View
For a web startup, the purpose of Customer Discovery is to identify a problem worth solving, defining the %u201Cright%u201D minimum viable product to build, and testing the business model using 3 separate Build/Measure/Learn loops. Most web startups rely on a product website for distribution and blogs, SEO, SEM, for initial customer acquisition channels- leaving price as the biggest unknown in the business model.

Sidebar: There is a somewhat loose definition of how the term MVP gets used. Many have used it (myself included) to refer to anything (a landing page, a problem presentation, screenshots, etc.) that allows you to learn about customers with the least effort. Here, I am using the stricter definition of MVP to mean the minimum set of features needed to learn from earlyvangelists. In other words, Release 1 of your Product.

It All Starts With Stating Your Assumptions

Before you can test what you think you know, you have to write it down. It%u2019s normal to try and short this step but I found it to be a very worthwhile exercise. Apart from minor terminology changes, most of Steve%u2019s questions in his hypothesis worksheets hold up even for a web startup. I am not going to reproduce them here but if there is interest, I%u2019ll make my versions available as a separate download.

Test the Problem

This will look very similar to Steve Blank%u2019s flow. That%u2019s because when it comes to Customer Discovery I haven%u2019t found a more effective way for maximizing validated learning than %u201CGetting out of the Building%u201D. This is coming from someone who used to prefer to stay in the building and talk to customers over email. Now, I have an 800 number tied to my mobile phone and schedule for face-time opportunities with customers.

With my last product, I used a teaser/landing page with some pre-launch buzz to collect email addresses and measure interest. While it was encouraging to have interested users, it told me nothing about what problem they had, who they were, what I should ship first, or what I should charge. What does 10 email addresses a day tell me? What does 20, 40, 100? Why did the other 70% abandon my landing page? Was it the product, was it the copy, graphics, something else. What?

Building a good landing page is hard. Unless you have exceptional customer insight (or are your own customer), iterating without talking to customers is slow and painful as you split-test one page against another with very little initial test traffic. Yes, it feels like more legwork to find people who will have a conversation with you but a 15 minute unscripted conversation has more validated learning pound for pound than all the data you can crunch from web analytics.

I have never tried using surveys with my landing page registrations because I hate filling them out myself. Plus, to make them easy to fill, you have to be very specific which assumes you know exactly what you want to know, which is hardly the case.

The beauty of Steve%u2019s process, is that it tests the problem separately from your solution.
To paraphrase Dave McClure:

Customers care about their problems NOT your solution.

During the %u201CProblem Presentation%u201D, you state the top 3 problems, then shut-up and listen which is key to getting it to work. It works because you aren%u2019t asking customers to validate or design a solution which addresses the %u201CCustomers don%u2019t know what they want%u201D argument. It works because it isn%u2019t a pitch. Actually, I take that back. It is a pitch. But it%u2019s the customer that%u2019s pitching their problems to you. I know I%u2019ve hit the right %u201Cproblem nerve%u201D based on how passionate a customer gets during an interview.

I like to structure my %u201CProblem Presentation%u201D like this:

1. State the top 3 problems
2. Ask customer to prioritize problems and identify any higher priority problems
3. Have customer describe how they solve the problem today
4. Very briefly describe how you might solve the problem
5. Ask Customer whether your approach would solve their problem
6. Would they use your solution if it were free?
7. Would they pay $X/yr?
8. Ask for referrals to other customers

Build Your MVP

Unlike Enterprise Software, which can be chock full of features, web startups need to focus on the smallest feature set needed to learn from earlyvangelists or the MVP. After the first reality check, you should end up with a prioritized top 3 problem list which drives the features for your MVP. I stress the importance of then building out the MVP to the point where it%u2019s demo-able. It will be hard for customers to visualize your solution without one. Screenshots and mockups may be used as stand-ins only if a demo is absolutely out of the question.

Test Your MVP

With the MVP built out, you then go test it against the original set of interviewees plus some.
I like to structure my %u201CProduct Presentation%u201D like this:

1. State the problem
2. Use the demo to tell a story of how your solution solves the problem
3. Test pricing again
4. Ask for referrals to other customers
5. End with a call to action: sign-up, or commitment to sign-up

Tip: I practice delivering the demo using screencasting software which not only lets me iterate till it%u2019s short and crisp, but I also end up with a video I can use later on the product website.

Iterate or Exit

The last step in Customer Discovery is to summarize what was learned and make a decision to iterate or exit.

What%u2019s Next?

Next time, I%u2019ll cover my flow for Customer Validation which I promise will look very different (from Steve%u2019s) for a web startup.

While I built this model specifically for my web startup, I feel the fundamentals outlined here apply to any type of web startup, with the exception of startups that *primarily* rely on high network effects, like Twitter and Facebook, where initial success metrics are user acquisition versus revenue based.

What do you think?

Print

PDF

Related posts:

1. Customer Development Checklist for My Web Startup %u2013 Part 2
2. How I learnt to grok Customer Development

–>

Tagged as: customer development, Customer Discovery