Getting it Built

1. Getting It Built From Idea to Launch BETTER PRODUCT CO

2. AGENDA 1. Introduction (15 minutes) 2. Burning Question Exercise (15 minutes) 3. Some Slides (30 minutes) 4. Questions and Answers (15 minutes) 5. More Slides (30 minutes) 6. More Q&A (15 minutes)

3. Introductions

4. INTRODUCTIONS 1. Who Am I? a. Andrew Gassen b. XAPPmedia, Pivotal Labs, Better Product Co, DevReady, Junyo, 360Ed, EA Sports c. Can’t code, can launch products d. Why this matters to me 2. Who Are You? a. Name b. Company Name c. Problem You’re Solving d. Biggest Fear

5. Write as many questions as you can in 5 minutes (One question per sticky)

6. Pick your TOP 5.

7. Got ‘em? Good!

8. Post your Top 5 on the wall. If others are similar, group them together.

9. Good Software is more than Code

10. THE RIGHT PROBLEM ● Perfectly crafted code is useless if nobody wants the product. ● Good products clearly solve a specific problem for a specific person. ● How do we know we have the right problem to solve for? ○ GOOB (Get out of the building!) ○ Exploratory interviews, not surveys or focus groups ○ Many potential users are feeling the same pains ○ The “Mom Test” ● Identifying the right problem significantly de-risks everything else! ● Example: ○ “I’m just starting my business and need an affordable place to work that’s not my kitchen table”

14. EXPLORATORY INTERVIEWS ● Ask open-ended questions ○ Tell me a time when… ○ That must’ve been hard, how did you… ○ If you had a magic wand… ● Don’t lead the user! ○ How great would it be if you had… ● Hunt for the problems they have, not specific solution ideas ○ Confirmation bias is to be avoided! ● Talk to 3-5 of each type of user ● Sticky note note-taking ● Synthesize!

15. UNDERSTAND YOUR USER ● What motivates them? ● How are they currently solving their problem? ● What’s their background? ● Is the User the same person as the Buyer? ● Make your user persona feel as real as possible ○ Give them a name ○ Draw a picture/find one on the internet ○ Refer to solving “Teri’s problem” in your head ● In what context(s) do they feel this pain?

16. Be passionate about your problem, not a specific solution.

17. IDENTIFY POTENTIAL SOLUTIONS ● Sketch! Like, really, sketch on paper. ● Come up with as many off-the-wall ideas that address your chosen problem. ● Use a clickable prototype to test solutions with your users ○ Invision is great for this! ○ https://invis.io/45C32JKUD#/137581041_List_Page

18. Take 5 minutes to list out things you need to do. (One per sticky)

19. Select your Top 5. Pass the rest to your neighbor to the right.

20. Ready?

21. Rip up the sticky notes you just got, and tell the author, “You’re welcome!”

22. PRIORITIZE RUTHLESSLY ● The 2x2 Framework ○ Do Now ○ Do Next ○ Seductive Distractions ○ Don’t Do ● There’s only one “Most Important” thing ● Solving one problem extremely well > addressing several problems poorly ● Why does this matter?

23. Deliver VALUE as early and often as possible.

24. DEFINING MVP Your Minimum Viable Product is not bad versions of lots of features. Your Minimum Viable Product is the smallest lovable solution to your biggest problem. You will probably be extremely uncomfortable with what your MVP actually is. (Psst...it might not be software!) And now, a silly example...

27. “I need to get from here to there faster than walking.”

29. OppsDaily.com The founder believed app developers wanted to be connected to people who needed apps to use. 1. Create a Mailchimp account 2. Throw up a landing page with a single input field 3. Mail out daily opportunities 4. Wait for interested devs to request a match 5. Request $25 via Paypal 6. Send an email connecting dev and customer Total dev time: about 8 hours

30. ITERATION Your software releases should be tied to value delivered to users, NOT new features. The longer you wait between releases, the riskier your product is becoming. A simple barometer: You have confidence about 2 weeks into the future at all times. Frequent iterations de-risk your product.

31. VALUE OF FREQUENT ITERATIONS

32. AGILE Iterative development practices are often referred to as “agile.” There’s an agile manifesto, check it out! Many flavors of agile exist: ● Scrum ● Extreme Programming ● SAFe ● Kanban

33. WATERFALL The “old school” method of software is commonly referred to as Waterfall. ● All the requirements gathered up front ● All the designs done next ● All the development done next ● Launch ● Oops we were wrong

34. Important Tech Terms and Concepts

35. TECH LINGO 101 To be a successful founder, you DO NOT need to be a developer. You should, however, be able to talk about the technology at a reasonable level.

36. TECH LINGO 101 ● User-Centered Design ○ The concept of designing to solve user problems, not deliver features. Validation with real users ● Clickable Prototype ○ Interactive designs that demonstrate workflow without building software ● Frontend ○ The parts of the application a user interacts with. HTML, CSS, Javascript ● Backend ○ The logic of the application a user never sees. Python, Ruby on Rails, Java, et al ● Database ○ The “bucket” where all your users’ stuff gets stored ● Web Application ○ Software a user accesses by navigating to a web address; Interactive, allows user input

37. TECH LINGO 101 ● Website ○ Static, non-interactive content accessed by navigating to a web address ● Native Mobile App ○ iOS or Android app built using device-specific languages; best performing option ● Hybrid Mobile App ○ Cross-platform apps built using web technologies and wrapped to appear mobile; lower performing ● API ○ Application Programming Interface; Allows apps to send data back and forth to each other ● Infrastructure ○ Where the software is deployed; AWS, Azure; “The Cloud” most commonly

38. BALANCED TEAM 101 The “Balanced Team” approach allows you to get coverage for all the major areas of your software development effort. It consists of: ● Product Designer ○ Interviews users, creates wireframes, creates target visuals. Primarily concerned with how value is delivered on an experience level, and representing the voice of the user. ● Product Manager ○ Writes user stories, prioritizes the backlog, removes blockers. Primarily concerned with what bits of value are delivered in what order. ● Software Engineer ○ Writes the code, releases the code, fixes the bugs. Primarily concerned about how the value is implemented on a technical level.

39. BALANCED TEAM 101 The ideal world is one person for each role. You don’t want to have solutions limited by an engineer’s poor design sense, or have technical details limited by a product manager’s lack of acumen. Even if you don’t have a person for each role, the responsibilities of each need to be accounted for to de-risk the effort. Protip: Look for “Full Stack” developers, they are best suited for delivering incremental value with limited hurdles.

40. Ok, Let’s Build It!

41. Case 1: I have money to spend

42. HIRE YOUR OWN TEAM Having a full-time, committed team is the best way to get bang for your buck. Incentivize them to share in the success of the company. Look for true partners, not “implementers.” Find folks comfortable and willing to work using an Agile methodology. Your success depends on it! Make sure you click on a personal level. Success will be hard to find if y’all don’t get along.

47. HIRE YOUR OWN TEAM Challenges: ● Expensive ○ A solid performer in each role starts over $100k in this area ● Finding a rhythm ● Getting buy-in on the vision and direction ● You’re likely to give up equity

48. HIRE A FREELANCER Freelancers are happy to work for you (for as long as you can pay them.) If you have an established process and set expectations, they can easily fill in. Check their portfolio, ask for references. Understand their availability, make sure you have shared expectations. Look for someone local, or at least someone willing to spend hours on video chat daily collaborating. Beware low-priced freelancers. You get what you pay for.

54. HIRE A FREELANCER Challenges: ● They aren’t incentivized to make your company successful ● If you take a break, it can be hard to re-hire when needed ● Difficult to predict or scale number of hours needed ● Tough to know what rate is a good value ● Hard to build the “team” cohesion with several independent freelancers

55. HIRE A CONTRACT FIRM There are many successful, talented firms of all shapes and sizes that can deliver software on your behalf. Check their customer references, check their portfolio for quality work or software similar to yours. Do a Google search, Glassdoor, Quora, Twitter. People talk. Have a plan for continued development when their time ends. Software is never done!

59. HIRE A CONTRACT FIRM Challenges: ● Very Expensive ○ You’re paying for salaries plus markup ● Extra level of management overhead for you ● They aren’t incentivized for product success, they’re incentivized to finish their scope of work ● They process they use may not match your needs ● Hard to set up long-term support arrangement at a reasonable price

60. Case 2: I have no money (yet)

61. BUILD YOUR OWN TEAM Having a full-time, committed team is the best way to build a balanced dev team. Incentivize them to share in the success of the company. Look for true partners passionate about the problem you’re solving. Make sure you click on a personal level. Success will be hard to find if y’all don’t get along. Find people who can commit to the level that you need.

62. BUILD YOUR OWN TEAM Challenges: ● Hard to find folks willing to work for free ● Accepting someone that can help you vs someone who can’t but wants to ● Getting buy-in on the vision and direction ● You’re almost guaranteed to give up equity ● Earning trust

63. CODE IT YOURSELF If you can build it yourself, why not? There are many advantages to building the first version of your software. ● Something to show people ● Get something out there without paying much ● Don’t give away any equity ● Working software > Pitch Deck ● Prove to your investors and team members that you’re serious about this ● Learn the complexities of the software you’re trying to build

64. CODE IT YOURSELF Challenges: ● Coding software takes time away from doing other activities ● You might not know how ● Watch out for compromising on your needs due to your own technical limitations ● You may become married to the code you wrote, making it difficult to throw out or refactor later

65. BUILD IT YOURSELF, NO CODE There are many platforms out there today that allow you to build mobile and web apps without writing a single line of code. For real! You can test your ideas crazy fast, release software crazy fast, and make changes based on learnings crazy fast. It’s just crazy. And fast. Low cost, low effort way to get real, paying users without breaking the bank.

66. BUILD IT YOURSELF, NO CODE Challenges: ● Platforms may not scale to millions of users gracefully ● Still takes up your time and attention ● Vendor lock-in ● Learning a very, very specific skill ● If you need something that isn’t supported, you’re out of luck

67. Let’s Talk About Codeless Tools

68. DROPSOURCE Dropsource lets you build native iOS and Android mobile applications. Recently raised a Series A ($5.4 million) PawBoost built with Dropsource You can actually get the iOS and Android code exported to hand to a developer Currently free while in beta Extremely powerful, a bit tougher to use than other options

69. KINETISE Kinetise lets you build native iOS and Android mobile applications. Mature and very extensive documentation A bit pricey, but plans scale with your success You can actually get the iOS and Android code exported to hand to a developer The editor is a tad wonky, but you can build most things that you can imagine You can “Hire a Pro” to help out and work with you

70. IONIC CREATOR Ionic Creator lets you build hybrid iOS and Android mobile applications. Mature and very extensive documentation, with frequent updates No backend support You can export the HTML, CSS, and JS The editor is a bit limited, but most use cases will be covered Widely used by some big name companies

71. BUBBLE Bubble lets you build responsive web applications using a slick editor and without writing a single line of code. Very active community on the forums, several video courses available One founder raised $300k, another over $2.5mm All my web apps are based on Bubble Let’s do a demo

72. Other Helpful Resources

73. RESOURCES ● The Lean Startup by Eric Ries ● Silicon Valley Product Group: www.svpg.com ● Anything by Steve Blank ● Business Model Canvas and Lean Canvas ● www.howmuchtomakeanapp.com ● Built to Adapt (Pivotal Labs Blog): https://builttoadapt.io/ ● https://saijogeorge.com/website-builders/ ● Me! ○ andrew@betterproduct.co ○ Cell: 407-307-6049 ○ www.betterproduct.co

74. Summary

75. 1. Solve a real problem for real people. 2. Do one thing masterfully, not 10 things poorly. 3. Don’t wait too long before you release something. Build a little, test a lot. 4. Prioritize ruthlessly. You are the gatekeeper. 5. Don’t get too caught up on a solution, even if you came up with it. 6. You don’t need to code to build software. 7. It’s better to find out you’re wrong earlier than later.

Getting it Built

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Getting it Built

Ähnlich wie Getting it Built (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (15)

Getting it Built

Hinweis der Redaktion