• Demoing your work to potential users (Product management)

Learning resources

• Atlassian - Project Management

Misc links

• 2014(?) - IAmNotAProgrammer - What is Soylent's 'job to be done'?
  
  • "What they found was that the job people were hiring a milkshake to do, it did better than any other food they sold."
  • The main takeaway I got from it was that asking your current / potential customers what you should do to make them buy may not be as productive/reliable as asking them questions that give you a very reliable understanding of why they're buying your (or some other) product.
• 2016.08.02 - Michael Seibel - Product Development Cycle Fundamentals
• https://www.quora.com/How-does-the-product-management-function-vary-among-companies-like-Google-Facebook-Apple-Microsoft-etc
• http://blog.miguelgrinberg.com/post/simple-project-management-or-how-to-finish-your-project-before-the-world-comes-to-an-end
• Quora - Why are software development task estimations regularly off by a factor of 2-3?
  • Rec'd by Carl on his FB

  • I liked Michael Wolfe's answer

  • I liked this answer:

    • I've contributed code to -- and, in most cases, also managed or co-managed -- software development tasks as small as 7 people (Crash Bandicoot) and as large as several hundred people (ITA Software's multiple person-millennia airline reservation system effort).
      
      As Arun Shroff said, you can find the long answer in Fred Brooks' Mythical Man-Month.
      
      The shorter answer, in my experience, is that most software development projects are much less well understood at their outset than equivalent physical world projects, because they can be.
      
      Software is completely intangible; it doesn't require big machines to dig holes or move heavy objects. It doesn't require complex permitting or regulatory approval. And a single talented programmer can create a very large amount of code very quickly -- to the extent that a very capable single developer can actually create an entire shippable product him or herself. Contrast this with, say, a single worker attempting to build an entire skyscraper alone. The "virtual" aspect of software completely changes the rate at which products can be constructed, and the resources required. But there's a rub...
      
      The other side of the coin is that because software can be developed without extensive planning -- and even without a complete understanding of the problem to be solved -- the market often demands that it be done this way. Put another way: nobody asks a small contractor to build a gigantic building in 6 months, but customers routinely expect software companies to perform the equivalent software task.
      
      A consequence of this is that software development is typically a process of discovery: the developer learns what needs to be developed as the product evolves. And what's worse, customers generally expect they can change their minds during development without dire consequences -- "how hard can it be to change the way that menu works?" -- which leads to frequent "scope creep" and moves the goal posts as the project progresses.
      
      The software development community has reacted to this overarching challenge by experimenting with new, so-called agile development methodologies. The details vary among these methods, but they all share a more iterative approach incorporating regular doses of feedback from customers prior to shipping. Indeed, under many of these methodologies, "shipping" is really only an arbitrary state one enters for political or contractual reasons; the goal is often to have whatever bits of the system are already implemented work reliably and receive thorough, automated testing, continuously. 
      
      These agile methods help ameliorate the difficulties of discovering-while-developing, but by no means make them go away. A significant advantage they offer, in my experience is diagnostic: it's easier to tell where "the progress bar" is using an agile methodology, because you are constantly diagnosing your current state and trying to course-correct appropriately.
      
      To (finally) answer your direct question, it's much more likely that your estimate will be off by a factor of 2, 3, or 10x when you have relatively little idea what you're creating, and need to "discover" what that product is via iteration and feedback, than it is when you know exactly what you're making from day 1.
      
      When building something (nearly) completely understood at the outset -- e.g., a typical physical product like a bridge, dam, or skyscraper -- the classic Waterfall and similar methodologies are far more accurate and effective -- and progress can be tracked with familiar tools like Gantt charts, which provide detailed data on progress to date.
      
      Finally, there are some kinds of software that are necessarily developed using Waterfall-like methods. These are projects where the consequences of failure are extremely dire. If an avionics system fails catastrophically, the potential damage is obviously far greater than if, say, Twitter is down.
      
      Projects like these take vastly more resources, planning, and process to accomplish successfully than their less risky peers. As a consequence, they are often extremely expensive. This is why making the guidance system for a missile is substantially more expensive to make than, for example, an email client (which is what I'm doing now).

• 2017.02.16 - Level 12 - Tank vs. Milk Truck
  • MI: Don't try to think up all of the specs you need ahead of time and build an app in one go. Start with a quick, cheap, simple version of some app that you want to create, and start using it ASAP. You'll learn things from using it that you can use to build gradually-larger and more-complicated (and more expensive) versions that will better-match your actual needs than what you would have thought up.