2 00. Bootstrap & Act

1. 200. Bootstrap & Act Get out of the building Nikos Palavitsinis, Agro-Know

2. Definition Adjective (of a person or project) using one's own resources rather than external help.

4. Structure • Revisit our Lean Canvas • Three Stages of a Start-up • DefineExperiment • Identify your Risks • Seek Advice • Experiments, Interviews, Scripts & Forms • Collect Data & Report

5. 201. Revisit our Lean Canvas

6. 202. Loose ends have to end!

7. 203. Three Stages of a Start-up • Do I have a problem worth solving? • Have I built something that people want? • How can I scale this up?

8. 204. What’s an Experiment? a scientific procedure undertaken to make a discovery, test a hypothesis, or demonstrate a known fact.

9. Validated Learning Loop

11. Steps • Understand the Problem: Conduct customer interviews or use other customer observational techniques to understand whether you have a problem worth solving. • Who has the problem, what is the top problem, and how is it solved today? • Define the Solution: Take a stab at defining the solution, build a demo that helps the customer visualize the solution, and then test it with customers. • Will the solution work? Who is the early adopter? Does the pricing model work?

12. Steps • Validate Qualitatively: Build your MVP and then soft-launch it to your early adopters. Do they realize the unique value proposition (UVP)? • How will you find enough early adopters to support learning? Are you getting paid? • Verify Quantitatively: Launch your refined product to a larger audience. Have you built something people want? • How will you reach customers at scale? Do you have a viable business?

13. 205. Identify your Risk

14. Risk A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome

17. Product Risk • Getting the product right • First make sure you have a problem worth solving, • Then define the smallest possible solution (MVP), • Build and validate your MVP at small scale (demonstrate UVP), • Then verify it at large scale

18. Customer Risk • Building a path to customers • First identify who has the pain, • Then narrow this down to early adopters who really want your product now, • It’s OK to start with outbound channels, • But gradually build/develop scalable inbound channels—the earlier the better.

19. Market Risk • Building a viable business • Identify competition through existing alternatives and pick a price for your solution, • Test pricing first by measuring what customers say (verbal commitments), • Then test pricing by what customers do, • Optimize your cost structure to make the business model work.

20. Ranking of Business Models • You may find yourselves with more than one canvases filled out • This may happen in case of different problems for different customer segments • But how do you decide on the one to act upon?

21. Weights • Customer pain level (Problem): Prioritize customer segments that you believe will need your product the most. • Ease of reach (Channels): If you have an easier path to one segment of customers over others, take that into consideration. • Price/gross margin (Revenue Streams/Cost Structure): Pick a customer segment that allows you to maximize on your margins.

22. Weights • Market size (Customer Segments): Pick a customer segment that represents a big enough market given the goals for your business. • Technical feasibility (Solution): Visit your Solution box to ensure that your planned solution not only is feasible, but also represents the minimum feature set to put in front of customers

23. 206. Seek External Advice • Get out of the building • Find “advisors” • Prototypical customer • Potential investor • Other entrepreneur • Ask specific questions, 20% setup – 80% talk, talk to visionary people, don’t take their input as validation or judgement

25. 207. Running Effective Experiments

27. What to do? • Measure one thing: Stay focused on the key learning or key metric you need to achieve, which will vary by the type and stage of your product, • Do the smallest thing possible to learn: Challenge yourself to find the simplest thing you can do to test a hypothesis, • Formulate a Falsifiable Hypothesis: Don’t accumulate just enough evidence to convince yourself that your hypothesis is correct, • Validate Qualitatively, Verify Quantitatively: Your initial goal is to get a strong signal that typically doesn’t require a large sample size,

28. What to do? • Correlate Results back to Specific Actions: Inform your product development in really specific actions from your side, • Create Accessible Dashboards: Share your experiments and their results, openly with your team, • Communicate Learning Early & Often: Periodically communicate the lessons learned from your last batch of experiments.

29. 208. Interviews a meeting of people face to face, esp. for consultation

30. No surveys – No focus groups!

31. Why? • Surveys assume you know the right questions, • Surveys assume you know the right answers, • You can’t see the customer during a survey, • Focus groups are just plain wrong, • Maybe you can use surveys to validate what you learn from your initial interviews

32. Tips • Build a frame around learning, not pitching. In a learning frame, the roles are reversed: you set the context, but then you let the customer do most of the talking, • Don’t ask customers what they want. Measure what they do. It’s fairly common to find customers lying in interviews, out of politeness or they really don’t know or don’t care enough, • Stick to a script. You need to bind the conversation around specific learning goals. Otherwise, you can blow off a lot of time and end up with an overwhelming amount of unactionable information, • Cast a wider net initially. Not all of your prospects will (or should) be early adopters,

33. Tips • Prefer face-to-face meetings. Pick up body language, connect and communicate. Create a sense of closeness, • Start with people you know. Get comfortable with your script, rehearse it. • Take someone along with you. Might help with documentation and following the script in case something is overlooked, • Pick a neutral location. Create a casual atmosphere, not make it business-like from day 1. Let them choose the place if they want to,

34. Tips • Ask for sufficient time. Let them know how much time you will need and stick to this. Don’t ask them 30 minutes and keep them occupied for three times the time, • Don’t pay or provide other incentives. You want to attract customers, truly, you don’t want to pay their kind words, • Avoid recording the interviews. Don’t make your interviewees think about what they are about to say 2-3 times before they say it, • Document results immediately after the interview. Get five minutes alone with silence and document all the results on paper.

35. These do NOT apply • Customers don’t know what they want, • Talking to 20 people isn’t statistically significant, • I only rely on quantitative metrics, • I am my own customer, I don’t need to talk to anyone, • My friends think it’s a great idea,

36. These do NOT apply • Why spend weeks talking to customers when I can build something over the weekend? • No need to test the problem, it’s obvious, • I can’t test the problem, it’s not obvious, • People will steal my idea

37. Be prepared Before venturing into the unknown, you need a thing or two…

38. 209. Prepare your Interview Form & Script • An interview script • To follow by the letter • An interview form • To help you document everything • A data collection/analysis instrument • To make sense of it

39. You need to know • Product risk: What are you solving? • How do customers rank the top three problems? • Market risk: Who is the competition? • How do customers solve these problems today? • Customer risk: Who has the pain? • Is this a viable customer segment?

42. Example • Idea: Build a tool/service/process that would help Project Managers prepare proposals for EU-funding • We got three problems • A list of possible interviewees • Booked the appointments

43. Story • Recently we found ourselves in the middle of yet another proposal preparation to secure funding for this amazing idea we had for one project. Following all the typical methods and tools to prepare the proposal, with a highly skilled team supporting it, we did submit it and we were more than positive related to its results. Getting the results back, we found out that the proposal was not accepted, reaching a really low score. What was worse, looking at the remarks made, they did make a lot of sense and we were really surprised how we did not address them at the first place.

44. Story • There and then, instead of blaming it on our tiredness, the magnitude of the proposals submitted for the same call, the politics or the weather, we decided to analyze the causes of our failure and try to trace them back to specific things that could have been improved. Looking at that, we find ourselves with a bunch of problems that were related either to the process or specific people that we would like to share with you and ask for your honest feedback on whether or not these problems look familiar for you and if you have faced them in the past. It’s really useful for us to learn about the problems you have to contribute as well as the ways you use to tackle them.

45. 210. Making sense of it all • Review results weekly • Home in on early adopters • Refine the problems • Understand alternatives • Essence lies in the detail (words) • Find ways to reach your early adopters

46. 211. Collect Data & Report Findings • Identify the demographics of early adopters • Build an archetype • Have a must-problem • A burning issue that has to be resolved! • Have accurate alternatives • What do customers use today?

47. Initial Problems • There’s a slow and problematic Proposal/Bid Development • When preparing a proposal we are not matching brainstorming & discussion outcomes into tangible proposal/bid contributions • Having difficulty in analyzing existing funding opportunities & identifying project ideas • Identifying appropriate project roles and partners to match them is a difficult and troublesome task that needs addressing

48. Final Problems • Problems with excessive communication overhead with partners and unnecessary interactions that get in the way of real work • Problem of slow collection of partner input for the various stages of a proposal • Problem of low engagement of the majority of the partners in the proposal preparation