Inspired by: http://www.stanford.edu/class/e140/e140a/handouts/ProductMgmt.txt

Good software projects have clear business goals and objectives. Everyone on the team has an understanding of what metrics will be used to define success. i.e. Implementing these changes to the sign up flow will increase paid conversion rates. Bad software projects are driven by the loudest voice in the room and based on personal preferences. Success cannot be measured because it was never defined.

Good software projects are built initially for a specific target audience based on customer development and hypotheses. i.e. We interviewed 100 used car salesmen and found out their most time consuming task is following up with potential buyers after test drives. Let’s build a mobile web app to let them take notes and send follow-ups while they are still with customers. Good software projects start by doing one thing 10x better than anyone else. Bad software projects are built for everyone. These projects are incrementally better then their competitors and try to “out-feature” them. They are everything for everyone and fall short. They are built because they could, not because they should.

Good software projects have a plan to acquire users after launch. i.e. Through our landing page we’ve accumulated over 1000 emails. We also started a influencer campaign with the top bloggers and Klout scorers in this space. We’ve also set aside $2,500 to test Google Adwords and Facebook campaigns. Bad software projects rely on hope and a ”build it in and they will come” mentality.

Good software projects have a shared sense of ownership and are built with passion and love. Everyone is willing to step outside of their comfort zone to learn new things and attack new problems. Bad software projects have people finger pointing, and people who live within their title and place. “I can’t fix this, I’m just a junior developer. Ask Joanne, she wrote this.”

Good software projects have teams who pay attention to details without getting hung up on them. They are able to make decisions quickly and move on. Everyone working on the project has context. Bad software projects are built by teams without expertise. They spend weeks arguing over the shade of green on a button.

Good software projects release software as frequently as possible and get constant customer feedback. They have product owners who have a deep understanding of their users and are able to prioritize features. Everyone tests and logs feedback. Bad software projects stay in a black box for weeks and when finally released are underwhelming. Everything is equally important.

Good software projects ship, measure and learn. Bad software projects don’t.

Related posts:

  1. Why free software usability tends to suck
  2. The Top 6 Mistakes Idea Stage Entrepreneurs Make
  3. Good Bug Tracking (aka How to make developers not want to kill you for logging ambiguous bugs they cant reproduce)