Email To My Brother – A Crash Course on Product Development

Let me talk about a hypothetical situation – say you’re my brother, a brilliant guy (scored 180/180 on the LSAT) who has dabbled with algorithmic trading, and practices law by day. An acquaintance introduced him to somebody who wanted a new SaaS product for their large, finance-related online community. Due to his combination of skills in law, finance, and programming, my brother has the chance to deliver an exciting new product. The only thing left to do: learn how to build and deliver a product from idea to launch to iteration.

He wanted a crash course in product thinking and product management to learn useful skills and processes around developing a software product. He wasn’t looking to start a billion dollar, high-growth startup. He just wanted to build something to satisfy his users’ needs, and something he could deliver. He was crunched for time, because his new contact wanted to keep the conversation going at a fast pace. Here’s what I told him:

Don’t build anything, yet

  • Do the Amazon style press release here
    • This document outlines the basics: the product, its users, what problem you’re solving. It should be the guiding force to refer to during the products life. It’s a simple, powerful, useful exercise. Do it!
      • It will be helpful to do the Amazon press release with your new contact, so you’re on the same page about the big picture.
  • Validate, validate, validate
    • Normally I’d follow this strategy here. Much of it is still applicable to satisfy your end users. But in this case, you also have to understand what your stakeholder (the new contact) wants you to build. What problem he’s trying to solve, how, and what he thinks of the market (his users).
  • Read The Lean Startup by Eric Ries – ideally the whole book. It’s foundational in startup land on process and how to maximize your time and effort by optimizing for learning. By testing small hypotheses, you will avoid spending lots of energy on paths that lead nowhere. You will do as little as possible to learn as much as possible, which is faster, cheaper, and easier in the long run. Because you’re crunched for time, read:
  • NOTE: These steps might take weeks or months

OK, now you’re ready to start building something, kinda

  • Build an MVP
    • The smallest, shippable useful thing you can make to test assumptions, validate ideas, and get feedback. You’re like a scientist here. You will not and should not try to build or ship the total vision, a complete thing. What you ship does not solve all the problems and pain points. It might be a video, a landing page, or an ad. Read this: Your goal is to learn quickly, so you get to building the right thing quicker. So ship something small to learn.
    • Internalize this image:crop-minimumViableProduct
      • It’s amazing. Look at it again. Your MVP can’t just function ok and be ugly. It has to have a little of everything – functionality, usability, beauty. Again, you might not need to be building anything substantive yet. It might make sense to build a video, a landing page, an ad, or mimic a functioning service when you’re the actual person making it all work. You’re MVP might not have much in terms of function or usability or looks – it’s their so you can test assumptions, learn, and get feedback.
    • What’s an MVP? The smallest thing you need to launch. “So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible.”
    •  A minimum viable product is “that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on”.
  • Keep validating (figuring out assumptions, hypothesizing, testing) 
  • Keep referring to and refining your Amazon press release
  • NOTE: These steps might take weeks or months


OK, now you should continue building, shipping, and iterating

  • This image is so great, it’s worth looking at again and again. Now, if you already built step 1, build steps 2-5, starting with 2. If you haven’t, build step 1:MVP
  • Similarly, if you already build step 1 here, build step 2. If you built what was in the thought bubble, now build step 1:


  • Read Rework by Jason Fried and David Heinemeier Hansson.
    • Each chapter is 1-3 pages with a picture. It’s not just beautiful as a model for a book, this makes it super useful for readers. This book gets to the point, each and every page. You can read it in bits and pieces – revisit it early and often. I don’t agree with every single chapter, but it’s filled with great ideas, and it’s thought-provoking.
  • Bonus links on MVPs
  • Bonus mantras from Y Combinator (a program that helps companies succeed, mostly software companies)
    • Make something people want.  You can screw up most other things if you get this right; if you don’t, nothing else will save you
    • Do things that don’t scale
    • A small number of users that love your product is better than a lot of people that like your product
    • Solve your own problems
    • Release early and iterate
    • You make what you measure

Key takeaways:

  • Approach things like a scientist. Identify assumptions, make hypothesis, and test them. Validate or disprove them.
  • Try to maximize your resources by validating early and often. Break things down into small, testable pieces.
  • Understand what a Minimum Viable Product is, and build it. Cut away the excess. Then cut away more. Maybe now it’s the MVP. Test it and get some feedback.
  • Build something people want. Give it to them so you can get feedback. Use that feedback well.
  • Talk to users frequently


Best of luck!