How is the Dry Creek Grill like software?Soft launchRestaurant was doneMenu was doneHiring was doneExperienced Restaurateur (Tomato Thyme next door)Soft launch last summerLimited, controlled reservations20% discountFollowup feedback at end of meal with the owner
Customer wants this as a main course
But we serve first because it is doneIf you’re opening an ice cream shop, this might be perfectly acceptable.Done and launchable are relative. Who is the target?What are their expectations?What is the product?
Our apps are small platesEach serving is complete, not just “done”. The potato is not only cooked, the presentation is complete.Each deliverable doesn’t have to be an entire meal to be satisfying,
Development focuses on the minimal.
Limited availability in 3 cities before scaling
Limited availability, built momentum and anticipation built
Beta Test InitiativePenny and Leonard start dating again. But Penny wants to take it slow. He asks her if she’s familiar with the typical development of computer software. A trial run, fix the bugs. Penny says, like a beta test?He says, technically this would be an alpha test and he goes on to say why. She interrupts to say, Seriously, I don’t get credit for knowing what a beta test is??
Not helpful. Inside out, not outside in. If you are going to talk about these “milestones” keep them to you and the dev team. It is NOT helpful to the rest of the organization because everyone has a different opinion about what each of these means. Done – we’re never done. Stop talking about being done. When you say done and a sales person is in the room, they think it’s ready to sell.Potentially “shippable” – as we move to the cloud, we’re not shipping anyway. Potentially shippable for what purpose? Selling? Marketing? Using? Validating? In my experience, it “compiles” and the regression tests passed.Dev ready – reinforces us/them. The “team” needs to be more collaborative, iterative. This is a serial, waterfall concept, not rapid iteration. See “done”.Beta – let’s stop using this term because it has so much baggage. And you can’t wait until beta to get feedback. The original definition of beta was testing your product in a customer’s environment to find things you’d never find on your own. Configurations, devices, real world. In parallel, we should be looking for early adopters who can be our first references, and grow it from there.We need validation of problems, design solutions, UI, UX early and often, from the beginning. Start with business value, what is the minimum viable product, the design, all the way through, will it work for customers? What was intended to happen with beta cannot wait until right before the product is “released”.
What is the market opportunity? [http://www.svpg.com/assessing-product-opportunities/]1. Exactly what problem will this solve? (value proposition) 2. For whom do we solve that problem? (target market) 3. How big is the opportunity? (market size) 4. What alternatives are out there? (competitive landscape) 5. Why are we best suited to pursue this? (our differentiator) 6. Why now? (market window) 7. How will we get this product to market? (go-to-market strategy) 8. How will we measure success/make money from this product? (metrics/revenue strategy) 9. What factors are critical to success? (solution requirements) 10. Given the above, what’s the recommendation? (go or no-go)We determine this before we build it.Pragmatic Marketing: urgent, pervasive, willing to pay? [www.pragmaticmarketing.com]What’s your business model? Worth the time and $? To someone?You might create a freemium (usable) product. BUT something needs to be sellable.
We don’t have to test how usable it is with the entire world, but we should look for REPRESENTATIVE users who are targets for us. (Hopefully there are enough of them out there to help us achieve our revenue goals.) Complete ENOUGH. First iPhone. Had email. Didn’t support exchange. That came later.Is it complete enough for the USER?Does it delightWill users recommend it?Chunk it up, serve small plates, but each plate is delightful and people will recommend it to their friends who tell their friends.
We need to get support ready for when we make the product AVAILABLE.Are the support services “repeatable”? Are we building a knowledge base and support onboarding PROGRAM so we can scale this as we get more adoption? Have we built the product to require LESS support? Are there answers available for the DIY’er versus someone who wants to talk on the phone?Will the initial support be timely? Based on the type of product or service you are creating. From April 10-15, if you have tax software and you can’t get a real person to respond, you’ll probably have a problem. If you’re there for them, even if they have a problem but you’ve solved it in a timely manner, you’ll probably rate a recommendation.
Now it’s time to start “releasing”. When I was “release queen”, there was a joke that we didn’t release products. They escaped.This should follow a repeatable process. When the product is complete enough and good enough for the problem you solve), make your product available to an exclusive, manageable group of users.Are risks manageable?Recruit early adopters who are willing participants.How risky is it if the product has problems?Can anyone lose a lot of money?Will anyone go to jail?Will this cause a panic?Will customers lose confidence?Iterate rapidly to eliminate the problems without gold-plating!Aim to get people to recommend you.
Increase availability until it’s completely open. 50 to 500 to 5000 and beyond!Same questions as you add to the pool. are participants willing, are risks manageable, will they recommend.
By now you should have references and credibility about what you’ve done rather than just talking about what you’re going to do.Before the big splash, is the market ready to hear the message?Some industries have seasons. If you sell to education, you don’t launch in September. If you sell to construction, you don’t launch in June. (You might break these rules because no one else is launching then, but be prepared to be ignored. OR, be prepared for slower adoption.)Is marketing ready with all of the promotions and messaging assets?Is sales ready?Can people buy? Can you process the orders? Can you fulfill the orders?
If the product is sellable, usable, supportable, and available, it should be launchable.
How will you scale? You don’t have to be “at scale” for the future now, but you need a path to get there.Hopefully you built it on an architecture that allows you to scale easily so you don’t have performance problems as you add customers, as customers use the product day in/day out.Reminder: scalability for support, sales, marketing, services, delivery, fulfillment (whatever your business requires as you grow)
In the BEGINNING, you should set the right objectives and goals. We need to remind sales and finance what the goals are and how we’re tracking against them.
Without this, you won’t succeed. Version 1 is just the beginning. Again. Lather, rinse, repeat. Path to volume. People telling their friends who tell their friends who tell their friends…You might have a sellable idea, but if it isn’t also usable, the customers won’t be retainable. If you’re failing here, figure out why, fix it, iterate, refactor, re-release, re-launch, lather rinse repeat.
MINIMUM VIABLE PRODUCT A SET OF PRODUCT FUNCTIONALITY THAT CAN BEST BE DESCRIBED BY THE FOLLOWING PHRASE: “WELL, IT’S THE LEAST WE COULD DO.” SAEED KHAND E V I L’ S D I C T I O N A R Y F O R H I G H T E C H onproductmanagement.net/2011/04/07/worth- repeating-devils-dictionary-for-high-tech/