Startup Lessons Learned


Published on

Learn from the mistakes of others (me) before you do a startup. This is a high level talk about how software startups can easily go off the rails. Learn to identify the issues early and avoid them, from handling external integration to having an empowered product owner, and more.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • Everyone underestimates the complexity.\n APIs change all the time.\n The Internet sucks at reliability.\n Exception handling is awkward at best.\n Business people don’t get it.\n
  • \n
  • Conventions make things cheaper.\n Breaking conventions is expensive.\n Pick and choose carefully.\n
  • \n
  • Don’t try to learn to program on your startup.\nDon’t try to learn graphic design on your startup.\nDon’t try to learn to be a lawyer on your startup.\nBuild a team with experienced practitioners. \nGetting up to speed is hard and is REALLY expensive.\n\nYour most valuable asset is time.\n\nUnderstand your costs. Education is expensive in time and lost opportunity.\n
  • \n
  • They don’t allow you to learn.\n\nStart small and iterate.\n\nYou don’t know what you’re doing yet.\n
  • \n
  • The only thing that matters is what the client sees. \n\nIf the customer can’t see it then it’s not done.\n\nTell story about multi-tier apps and RIA’s.\n
  • \n
  • Right now you know the least you will ever know about your product, market, customers, etc.\n\nIterations allow you to learn and course correct.\n
  • \n
  • There MUST be a product owner.\n\nOne person who has complete and total authority to answer questions about how the product is going to work.\n\nWhat’s a camel?\n\nA horse designed by a committee.\n
  • \n
  • If you aren’t willing to share with someone you don’t trust them. So, don’t work with them.\n\nBusiness moves too fast and dependencies develop to quickly to work with people you don’t trust.\n\n\n
  • \n
  • You do not want to be figuring this stuff out when you’re trying to roll out your product under the gun.\n
  • \n
  • Do not depend on email, spreadsheets, or other non-shared documents.\n\nTools must be:\n\n* Shared\n* versioned\n* Support workflow\n\nCollaboration is paramount.\n\nEveryone must use the same tools! Figure out a set and agree on them.\n
  • \n
  • If your app is an integrated front end and back end system. Until the front end is integrated with the backend it’s not done.\n\nHaving API stories and disconnecting the integration work allows people to cherry-pick the easy stuff and leave the hard work for later.\n
  • \n
  • Do not try to manage content in your source repository.\n
  • \n
  • Startup Lessons Learned

    1. 1. Startup Lessons LearnedMark MenardBarcamp AlbanyMarch 31, 2012 (c) elycefeliz from Flickr
    2. 2. Integration is Hard 2
    3. 3. 3
    4. 4. UnderstandTechnical Limits 4
    5. 5. 5
    6. 6. Startup are not forLeaning the Basics 6
    7. 7. 7
    8. 8. Grand Openings Don’t Work 8
    9. 9. 9
    10. 10. Work Stories fromBeginning to End 10
    11. 11. (c) Al_HikesAZ from Flickr 11
    12. 12. Roll Out Iteratively 12
    13. 13. (c) Gerry Kirk from Flickr 13
    14. 14. There Can be Only One! 14
    15. 15. (c) Mashall Astor - Food Fetishist from Flickr 15
    16. 16. Transparency is Paramount 16
    17. 17. (c) Muffet from Flickr 17
    18. 18. Deploy Early and Often 18
    19. 19. 19
    20. 20. Document YourRequirements 20
    21. 21. 21
    22. 22. No API Stories Unless the Product is an API 22
    23. 23. (c) Julie70 from Flickr 23
    24. 24. Use a Content ManagementSystem for CONTENT 24
    25. 25. 25
    26. 26. I’m Mark Menard @mark_menardWe Build Web & Mobile Apps We Build Community We Build Startups 26