What's the measure of success for your project?

When I first started in the software industry I believed that the measure of success for any project was whether or not it shipped anywhere. One of the biggest surprises to me transitioning into the industry was how much software never actually ships. It baffled my mind (and still does) that people could work for weeks, months, or even years on software that would never ship.

What I've learned though in my career is that shipped software is not the right measure of success. USED software is the correct measure of success. No, not re-sold software. I mean software that is being used in the real world by real people/processes to solve real world problems.

Simply shipping software is not enough. Why? Because shipping software that is not used is the same as not shipping the software in the first place. Anecdotally, the top three reasons for software not shipping in my experience have been:

1. The team never reaching feature complete.

2. The project running out of money.

3. The requirements changing so fundamentally that it made sense to just build something else.

#1 and #2 are closely correlated in that #1 eventually leads to #2. All 3 of those situations are symptoms of having a broken process. So how do you fix your process?

Get a product owner

All good (i.e. used) software has a product owner. Someone who is responsible for making sure that the software being built is solving an actual problem and has people who need the problem solved. A good product owner doesn't search for a customer for the software. Instead a good product owner builds software that has people who already need it and figures out how to get it in front of them.

Focus on building individual features rather than a breadth of features 

All too often in the software industry features get built because of some gut feeling of some higher up in the organization. Don't build software this way, it's the easiest way not to have real users. Instead focus on a small feature set (one feature if at all possible) and build it, ship it, and iterate on it.  

Once you've got people using a feature you'll know the correct next feature to build because your customers will ask you for it. The key is, your existing customers. The ones that rely on your software to accomplish some task, will ask you to build something that they need/want. 

Release early, and often

I've talked about this many times but it bears repeating. The only way to build the correct thing is to get feedback on what's being built as soon as possible. The only way to do that is get something in your customers hands as soon as possible, gather feedback, and pivot in response to customers needs. The only real way to do that is to release early and often.