Product / Market Fit – Our Travels Towards It
•
2 gefällt mir•1,032 views
This talk was given on November 13th, 2012 in the LESS 2012 Conference in Tallinn, Estonia.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Product / Market Fit – Our Travels Towards It
Ähnlich wie Product / Market Fit – Our Travels Towards It (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Product / Market Fit – Our Travels Towards It
- 1. Product / Market Fit Our Travel Towards It Mikael Roos, Co-Founder
- 15. SO, HERE WE ARE NOW • Flowdock – Team Inbox With Chat • Started as side project, first launched in 2009 • Started work full-time in 2011 • Raised a seed round, now 9 people • Getting ready for a big “2.0” launch this month • Raising series A starting in January
- 16. PRODUCT / MARKET FIT PRODUCT MARKET FIT Learn Scale
- 17. CUSTOMER DEVELOPMENT (STEVE BLANK) 1. Customer Discovery – Achieve Problem/Solution Fit 2. Customer Validation – Achieve Product/Market Fit 3. Customer Creation – Drive Demand 4. Company Building – Scale the Company
- 18. THE ONLY THING THAT MATTERS Is Product / Market Fit
- 19. Niche
- 20. A STARTUP IS A STORY Planning your pivots
- 21. TIME TRACKING
- 24. REAL-TIME SOCIAL TIME TRACKING WITH VIRTUAL PRESENCE
- 25. REAL-TIME SOCIAL TIME TRACKING WITH VIRTUAL PRESENCE AND COMMUNICATION
- 26. GROUP CHAT
- 28. CONTEXTUAL REAL TIME COLLABORATION Turn discussions into knowledge.
- 29. TEAM INBOX WITH CHAT Replace IRC, IM or Skype chat with Flowdock.
- 30. YOUR MARKETING MESSAGE The people who are in your target market and love your product, why do they love it?
- 31. BUSINESS MODEL
- 32. AN EXCEPTIONAL TITLE And this is quite the extraordinary subtitle. Experiments
- 33. REFACTORING AND how I stopped worrying and love the bomb
- 34. VisionPRODUCT VISION Shoulder fugiat ullamco, turkey voluptate consequat ground round. Et frankfurter dolore, nostrud speck consequat culpa tenderloin excepteur. Reprehenderit strip steak shank shankle, velit minim turkey in cow. Minim andouille eiusmod short loin, sed laboris reprehenderit shoulder.
- 35. Feedback PRODUCT VISION Shoulder fugiat ullamco, turkey voluptate consequat ground round. Et frankfurter dolore, nostrud speck consequat culpa tenderloin excepteur. Reprehenderit strip steak shank shankle, velit minim turkey in cow. Minim andouille eiusmod short loin, sed laboris reprehenderit shoulder.
- 37. SHOW OFF THE CUSTOMERS
- 38. SHOW OFF THE CUSTOMERS
- 39. FEATURES, AM I RIGHT? • Are the customers demanding it? • Or is it something you came up with and think is groundbreaking? • Each feature should be validated!
- 40. CONTINUOUS BETA Never stop the experiments
- 41. Launch
- 44. DON’T JUST SHIP IT, LAUNCH IT!
- 45. DON’T JUST SHIP IT, LAUNCH IT!
- 46. DON’T JUST SHIP IT, LAUNCH IT!
- 48. EXPERIMENT FEEDBACK MEASURE LAUNCH RE-IMPLEMENT = Most Learning
- 49. Vanity metrics: Total number of signups Number of visits Hits
- 50. Any cumulative metric Amount of realism 100 75 50 25 0 2007 2008 2009 2010
- 51. REAL METRICS
- 52. Acquisition Growth Activation Value Retention Revenue Revenue Referral
- 53. Customer Acquisition Cost Monthly Signups Signup Funnel Monthly Recurring Revenue Average Revenue Per User Customer Lifetime Value Churn Daily Active Use
- 54. 7.2 HOURS / DAY Average usage
- 55. CONVERSION FUNNELS 1000 Site visits 1000 3% Signup form 10% 15% Signups 35% = 4.5 signups = 30 signups
- 56. CUSTOMER SCORE
- 57. COHORT ANALYSIS 1st week 2nd week 3rd week 4th week 4 weeks 25 23 21 20 ago 3 weeks 25 23 21 ago 2 weeks 29 28 ago 1 week 30 ago
- 58. DIFFICULT IS GOOD GeoDNS Stunnel HAproxy HTTP WebSocket RSS IRC Streaming API Redis API Rails Message Backend MongoDB PostgreSQL
- 59. AWESOME Do you understand how awesome this is? Awesome
- 60. EVERY STARTUP IS DIFFERENT. DISCUSS! Mikael Roos twitter.com/livedo mikael@flowdock.com flowdock.com twitter.com/flowdock blog.flowdock.com
Hinweis der Redaktion
- \n
- Me practicing agile methodologies.\nFounded Nodeta in 2004, one of the first Ruby on Rails shops in Europe. Large projects.\nSee myself as an entrepreneur, but also a programmer, and a lover of products.\n
- One of the side projects we’ve built is APIdock.com, a social documentation site. 200k Monthly Active Users.\n\nDidn’t have a business model, but turned out to be a great exercise in terms of driving traffic to our other projects, learning, gaining traction in the Ruby community.\n\n
- Now doing Flowdock. \nStarted as side project to the consultation business. Had lots of assorted ideas about different businesses. Chose to build something to fix our own problems.\n
- Every time we started a new project, we argued about the toolset.\n\nWe learned that developers tend to live in a group chat - they use it all day long. Then there’s email, where you get thousands of automatic emails that you never read. There’s project management for tracking progress, and actual development also happens somewhere.\n\nCommunications are spread around. This kind of workflow is ineffective, very slow and error-prone.\n
- Every time we started a new project, we argued about the toolset.\n\nWe learned that developers tend to live in a group chat - they use it all day long. Then there’s email, where you get thousands of automatic emails that you never read. There’s project management for tracking progress, and actual development also happens somewhere.\n\nCommunications are spread around. This kind of workflow is ineffective, very slow and error-prone.\n
- Every time we started a new project, we argued about the toolset.\n\nWe learned that developers tend to live in a group chat - they use it all day long. Then there’s email, where you get thousands of automatic emails that you never read. There’s project management for tracking progress, and actual development also happens somewhere.\n\nCommunications are spread around. This kind of workflow is ineffective, very slow and error-prone.\n
- Every time we started a new project, we argued about the toolset.\n\nWe learned that developers tend to live in a group chat - they use it all day long. Then there’s email, where you get thousands of automatic emails that you never read. There’s project management for tracking progress, and actual development also happens somewhere.\n\nCommunications are spread around. This kind of workflow is ineffective, very slow and error-prone.\n
- Flowdock is a centralized communication hub for your team. It’s based on the group chat, that everyone’s already using. \nThus, we’re not another communication tool, but we’re improving something you already have.\nThat’s something we learned early on. People don’t want new tools on top of their toolset, they want to replace the tools they’re not happy with.\nOn the left you see a shared team inbox, that’s connected to all the other tools your team is using.\nThat makes your own e-mail inbox much lighter.\n\n
- Flowdock is a centralized communication hub for your team. It’s based on the group chat, that everyone’s already using. \nThus, we’re not another communication tool, but we’re improving something you already have.\nThat’s something we learned early on. People don’t want new tools on top of their toolset, they want to replace the tools they’re not happy with.\nOn the left you see a shared team inbox, that’s connected to all the other tools your team is using.\nThat makes your own e-mail inbox much lighter.\n\n
- Flowdock is a centralized communication hub for your team. It’s based on the group chat, that everyone’s already using. \nThus, we’re not another communication tool, but we’re improving something you already have.\nThat’s something we learned early on. People don’t want new tools on top of their toolset, they want to replace the tools they’re not happy with.\nOn the left you see a shared team inbox, that’s connected to all the other tools your team is using.\nThat makes your own e-mail inbox much lighter.\n\n
- So you would all share a single persistent chat room in which you can SEAMLESSLY talk over any and all activity, situations, things that are happening. So you get CONTEXT right in your chat client. And you can get just e-mail in as well.\n\nAs opposed to e-mailing a bunch of people to get specifically their attention to a specific issue.\nSolving problems in days vs minutes.\n
- Us in November 2011.\n\nStarted as side project, launched as side project, billed as side project.\n2011 started work full-time, bootstrapped, raised some money.\n
- The big picture: Product/market fit means being in a good market with a product that can satisfy that market.\nPM Fit is the only shared characteristic for a successful startup. You *can* do anything to get there and be successful.\n(Marc Andreessen)\n\nA plan that works, proven, scalable, repeatable business model.\n\n\n\n
- The step where you have an idea what your market should be, what your solution that probably will satisfy the market is, and you show it to people that represent the market. Then you make changes to a) the product, b) the market, c) the problem on their feedback. => validated learning\n\n(like the thing about customers wanting to replace a tool)\n\nMy favorite way of putting it: Go that way, really fast. If something gets in your way … turn. (Jeff Atwood, Coding Horror)\n
- #1 Killer Of Startups is A Bad Market - Marc Andreessen\nNeed to have a good idea of market in the beginning.\n- Don’t be technology looking for a market, new kind of silicone that has different qualities than anything before\n- A great team can’t beat a lousy market\n\nWe did not do this, started as a side project, something fun, building ourselves something useful.\nIn practice, you usually need to have a market roadmap. Some day we want Flowdock to be a business e-mail killer. At first, go for a niche.\n\n
- “A startup needs to Build for a Niche While Maintaining Broad Appeal”. (Chris Anderson, Head of TED)\nMeans that you need to initially focus on a niche target market but have a clear picture on how to move forward.\n\nOur niche: ourselves, "agile software developers", "technical teams", “service delivery”, “IT”\nOur broad appeal: sales team, support team, any team, business e-mail competitor\n\n\n
- The humanist in me wants to put it like this.\nSometimes the plot is very obvious but sometimes there's a twist.\nYoutube: from dating to internet video.\nCrossing the chasm - often means changing or at least extending your market, you need to change with it.\nProduct market fit is a moving target, you can lose it, you can get it back.\n
- Flowdock started as some ideas for time tracking\n- real-time web was in the horizon at the time, wanted to research it\n- social time tracking, wouldn’t it be cool to see what others are tracking == context\n- virtual presence, know who’s at work\n\nAt this stage somebody probably googled for time tracking and got the 0.5B hits.\nWait, this kind of seems like...\n\n
- Flowdock started as some ideas for time tracking\n- real-time web was in the horizon at the time, wanted to research it\n- social time tracking, wouldn’t it be cool to see what others are tracking == context\n- virtual presence, know who’s at work\n\nAt this stage somebody probably googled for time tracking and got the 0.5B hits.\nWait, this kind of seems like...\n\n
- Flowdock started as some ideas for time tracking\n- real-time web was in the horizon at the time, wanted to research it\n- social time tracking, wouldn’t it be cool to see what others are tracking == context\n- virtual presence, know who’s at work\n\nAt this stage somebody probably googled for time tracking and got the 0.5B hits.\nWait, this kind of seems like...\n\n
- Flowdock started as some ideas for time tracking\n- real-time web was in the horizon at the time, wanted to research it\n- social time tracking, wouldn’t it be cool to see what others are tracking == context\n- virtual presence, know who’s at work\n\nAt this stage somebody probably googled for time tracking and got the 0.5B hits.\nWait, this kind of seems like...\n\n
- Group chat is kinda lame. IRC was invented in the 80s.\nNo, we’re gonna do this awesome thing.\n\n
- We don’t know what it is yet, so we’ll call it...\nThis was actually good, since we didn’t know what we were building.\n\n
- Eventually it started dawning on to us, and we were able to define what we’re building.\n\nIf I actually have the energy to read all the words, then what does it mean?\nYou cannot sell this. Doesn’t replace anything. I don’t have the problem that my discussions aren’t turning into knowledge.\n
- Eventually we came to this. Simplicity and clarity, appealing for the target market.\nThe word team is key here. It sets the context. This product is for teams.\nBe sure to communicate the cool stuff behind too.\n\nThis is not the end of the road. We’re still going to build the teamwork revolution. Still gonna build the business email killer.\n
- Best way to get marketing material is to have your customers write it for you.\n
- Business model canvas, lean canvas. Here’s your storyboard. As with everything withs startups, you reiterate it.\n\nUseful to play with when thinking about new business ideas.\nDown the line, should be a social exercise. All employees should have a clear picture of what’s in it.\n\n\n\n\n\n\nTo begin with, we didn’t have a business model. “Basic SaaS business”. Idiots!\nA product is not a set of features, it is the holistic money making machine. The product is the business model.\n\nBusiness Model == Business == The Plan == Is the product\n\n\n\n
- Searching for the product market fit means: “Make small calculated bets on your ideas in order to validate them.” (Eric Ries) Backlog is extremely unclear at times. As it should be. No need to feel bad about it.\n\nWe created prototypes: process tool, task management app, mind mapping tool ... all thrown away because the customers didn’t want them. “That’s nice but where are the private messages.” Way too early with those features. And now we’re launching private messages this month.\nExperimentation important later, too.\n
- Not to be afraid of refactoring. Experiments should be cheap, dirty and fast.\nSometimes it’s easiest to continue by throwing it away completely. Much easier to cope with when you assume it’s going to happen.\n\nWe take software quality and craftsmanship very seriously. Refactor, rewrite! Anyways, that’s the best kind of programming, when it’s thoroughly clear what the business requirements are and the feedback is already in.\n
- Product vision you need to have. Sometimes you need to hold off on customers demanding features. Are they the target customer? — But most of the time, you need to look for feedback.\nGetting feedback from real customers is the single most important thing an early-stage startup can do.\n\nWeren’t very good at this in general, BUT: Feedback button in-app. People come up with a problem and tell it right away, rather than coming up with contrived solutions.\nLucky: Had highly engaged end users. Received thousands of feedback e-mails. Talked a lot with the customers.\n\n
- Product vision you need to have. Sometimes you need to hold off on customers demanding features. Are they the target customer? — But most of the time, you need to look for feedback.\nGetting feedback from real customers is the single most important thing an early-stage startup can do.\n\nWeren’t very good at this in general, BUT: Feedback button in-app. People come up with a problem and tell it right away, rather than coming up with contrived solutions.\nLucky: Had highly engaged end users. Received thousands of feedback e-mails. Talked a lot with the customers.\n\n
- Ask for money! \nCustomers took us more seriously, and we started getting better feedback. Should have done it earlier.\nQuestionnaires are good, but customer-initiated feedback is better.\n
- When you talk to your customers and try to understand their need, let other customers know about it!\n
- Must haves vs. Innovation – In the end you have to balance between.\nEach feature must be a validated fit!\n\nThe customers are usually more receptive to your awesome ideas when they have what they need.\n\n
- Betas are great for figuring out if you’re doing it right, \n* feature toggles\n* A/B testing for features\n\nThe 1 % Improvement.\n
- Launch!\nB2B Launches do not create client bases!\n\n\n\n\n\n\n\n\n\nCurrently doing separate private beta. They are dying to get in. In a few days half of our customers had tried it. Only make a big launch when you’re certain you have winning features in it.\n\n
- Launches usually looks like this.\n
- Launch at least every month. Newsletter! \nWe launch and re-launch, build a momentum.\nWe deploy to production several times every day.\nDriving traffic takes time!\n
- \n
- \n
- Landing pages. Throw-away. Good for testing the waters with different markets.\n
- Roughly, our current model, what fits us right now.\nExperiment - come up with a feature / market, problem, solution and make a bet experiment / implementation.\nFeedback - show it to the customers or try it out in the wild (eg. a/b in signup form).\nMeasure - If engagement or conversion drops, consider yourself learned, and go back to square 1.\nLaunch - Launch it, launch it big to your customers and try to use it as a tool for customer acquisition acceleration. Avoid learning too much at this stage.\nRe-implement - if everything worked great, refactor, redesign, re-do and release to beta again as a polished gem.\nRetrospectives work well!\n\n\n
- It’s easy to look at the biggest numbers you’re able to measure. Unfortunately, they don’t give a proper view to the performance of your business. Easy to go to the wrong direction if followed.\n\nWhen you’re choosing your metrics, only pay attention to what a metric can teach you, what can you learn.\nI would consider any metric that doesn’t let you learn things, a vanity metric.\n\nMetrics are also proof that your company is doing well. If you draw up a metric and decide you cannot learn from it, it still may be useful for showing to investors, that you’re creating value into the company.\n
- BTW: Don’t show things cumulative over time. That’s just stupid.\n
- Instead use real metrics that depict the reality well. You’re only fooling yourself.\n\nComing up with the right metrics is\n1) Absolutely imperative for your business\n2) Extremely hard and time consuming\n\n
- Acquisition. How do users find you?\nActivation. Do users have a great first experience? Do they convert?\nRetention. Do users come back? Don’t leave.\nRevenue. Money.\nReferral. Will they tell others.\n
- Actual Metrics\nThese are just some of the metrics we ended up measuring a bit later. Some of them directly related to money, and thus not applicable at very early stage.\n\n\n
- An average Flowdock user uses Flowdock at least once per hour for 7.2 hours per day\nCompetitors have a fraction of this.\n
- A Growth metric\nThe impact we got from A/B testing, website redesign, repositioning etc. was significant. And the work continues. Naturally affects customer acquisition cost.\n\nThen there’s another funnel from signup to a paying customer.\n\n
- We have a free 30-day trial, and we needed to iterate faster. Can’t wait 30 days to see if something’s working or not, so we introduced a “customer score” that helps us in guessing if someone’s going to start paying.\nComposed from activity metrics. Able to draw conclusions like customer score over 30 => 70% start paying.\n
- Once you’ve established your metrics, you don’t want to be looking at a single number. Instead, follow what’s happening over time. Used with customer score.\n\nGood for customer lifetime value. You want to know that new customers are creating more value than old customers.\nHoly Grail: close up signup form and still keep growing.\n
- A final thought: Do something that’s hard! It’s interesting!\n\n“How easy is it for someone else to provide the same product or service that you provide?”\n=> Difficult projects are great for maintaining a competitive advantage!\n\nEven if you could find a get rich quick idea, it would be easy to copy.\n
- Building a product / startup is so much fun! T-Rex in F-14!\nFeels like this is just the beginning! So much to learn.\nGo work in a startup!\n
- Disclaimer: these things do not apply to all startups.\n