by @abhia90 // newsletter // youtube

Link to Michael Seibel's article here

Note: Read this article only if you’ve already released an MVP and are figuring out what to do next

Purpose of this article?

• To learn the fundamentals of the product development cycle— This will help you rapidly iterate, measure, test, and improve your product while fully engaging your team. Note: This is not that same as shipping an MVP. As stated above, read this article assuming you’ve already released an MVP and are figuring out what to do next, which is where most startups spend most of their time.

Fundamentals of the Product Development Cycle:

1. Define your development cycle length
   • Cycle length is dictated by your product (Ex: 2 week cycle for iOS, can be shorter for web app, or longer for hardware)
   • The key is to structure the cycle so that teammates stay excited and still feel like they can brainstorm new ideas.
2. Determine your goal(s) and Identify the product lead
   • Ex: For Justin.tv, every product meeting was focused around one of three goals:
     1. Increasing content creation
     2. Increasing new users
     3. Increasing retention
     • Whichever goal they chose would be the focus of the meeting and, therefore, the next two weeks.
   • Product lead's job is to protect and improve the dev cycle, and to moderate the product meeting and give everyone a chance to speak (massively increases team buy-in of this whole process)
3. Organized and inclusive brainstorm

   1. Ex: write ideas on a whiteboard into these categories:

      1. New features/feature iterations
      2. Maintenance
      3. A/B tests

      Note: It's an open and non-judgmental forum; Everyone has to contribute, and nobody can be a dick and shoot down other people's ideas (again, this is maintained by the Product Lead)

   2. Take the ideas and then the engineers grade them into easy (<1 day), medium (half a day for 1 person), or hard (most of the dev cycle); If it extends into the next dev cycle, break the idea up into chunks

      1. This process really helps non-technical ppl understand the thought process of the engineers and subsequently helps the formation of leaner, easier MVPs
4. Building a consensus
   1. Start with the hard idea (b/c it allows everyone to focus on the (potentially) main task over the next 2 weeks) —> then the medium tasks —> then the easy tasks
5. Clear spec and clear measurements of success
   1. Spec out each of the items on your list in great detail
   2. Assign each item to a team member
   3. ****Spec out the stats/results you need to track in order to measure how effective the feature was
      1. If you dont have metrics, you cannot work on this item!
   4. Separate out the Need-to-haves from the Nice-to-haves on the list.
      1. If you don't have time for the nice-to-haves, they get cut (😢)
   • Remember, this product roadmap only lasts for the cycle time you alloted for (ex: 2 weeks). After that time period (ie the next product meeting), you start from scratch with a new goal, new analytics data from the past 2 weeks, and (hopefully) new insights from in-person user testing (try to do monthly)
6. Working during the development cycle
   1. Work on all the business/operation tasks
   2. Then look for interesting product insights or potential bugs
   3. Simultaneoulsy run a user testing session at some point during the month
   4. During the last 3 days of the dev cycle the team would stop building and just do testing (this sucks but is impt)

<aside> ⭐ All information is owned by Y Combinator. I claim no ownership of this information.

</aside>

by @abhia90 // newsletter // youtube