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.

Getting To The Next Level

Over the several years I've spent a lot of time mentoring, managing, and leading teams. For most of my career I was unclear what it meant to get to the next level. I thought that as long as I did a good job I would be recognized for my accomplishments in the form of career advancement.

While my career has advanced well, I missed several opportunities to move up simply because I was unaware of what it took to get to the next level. So here are some helpful tips that you can use to advance your career.

Make it known you want to be there

This sounds obvious, but you'd be surprised at how many people never let their bosses know they're looking to move up the career ladder. In the fast paced world we live in, you're not going to get something unless you ask for it. Taking this step is pretty simple. It just requires the courage to say you want it.

Identify Your Gaps

This is more difficult. Not because it's hard to figure out where we need to grow, but because it's hard to hear that we do need to grow. Even the most self-aware people I know can tend to gloss over the areas they need to grow in. When you sit down with your manager to let them know you want to get to the next level ask them these two questions:

What am I doing now that I need to stop doing?
What am I not doing now that I need to start doing?

Take the Opportunities presented to you

Getting to the next level is not just about skill. It's also about taking advantage of the opportunities presented to you and applying your skill, or learning new skills. The latter is more important because most likely, you need to learn a lot in order to start functioning at the next level. Every opportunity you take gives you a chance to both learn new skills and hone the skills you already have.

Look for opportunities that will stretch you in an area you're not comfortable with.

Be a Mentor

The best way to learn something is to try to teach it. You'll learn where the gaps are in your knowledge or skill set very quickly. A great way to do this is to start mentoring others. You'll be asked lots of questions you have no idea how to answer. But you then have an opportunity to get to the right answer and learn a new skill or some new knowledge along the way.

Get a Mentor

Having a mentor who is at or above the level you're trying to achieve is important. Having already achieved the thing you're trying to achieve makes them a good resource for you. Ask them that their hurdles were to getting to that level. Ask them what areas you should focus on and how to practice working at that level. Talk through situations and opportunities you currently have and see how they would respond or lead.

Most importantly listen. Being mentored isn't about showing the mentor how much you already know. It's about being humble enough to be teachable.

The Unlearning Of Technology

I grew up in the Washington D.C. area. I grew up a Redskins fan (whose name I DO believe should be changed). That also meant I grew up hating the Cowboys. My family (and extended family) had season tickets and I could go to 2 - 8 games a year. When not at the games I would watch them at home. I was almost religious in my dedication. I could tell you the names of almost every starter and a good portion of the bench.

I moved to Seattle 10 years ago and now I couldn't name 5 people who play for the Redskins. I'm not quite as fanatic a Seahawks fan as I was a Redskins fan, but I watch every game, go to as many as I can, and can tell you their record, their standing in the league and who the key players are.

Did I set out to become a Seahawks fan and not a Redskins fan? No, I just like football and fell pray to convenience and repetition. Not having Redskins games readily available made it hard to stay up with the current happenings. Not watching games each week I wasn't able to learn what the team was doing well today, learning where their defense was weak and their offense strong. Essentially, I was spending time unlearning what I knew about the Redskins.

The same is true in the software industry. You're only going to know the ins and outs of platforms, frameworks, and code that you actually spend time with. If you don't spend time with it you'll evolve and change on separate paths.

Given enough time, eventually you'll grow apart from the technology. You'll stop recognizing the subtle changes from version to version. You'll stop being able to speak to the differentiation of the platform or framework. You'll make stupid, or novice mistakes when you do dive in. You'll miss important aspects of design, architecture, or code quality.

This isn't always a bad thing. Sometime, in order to learn something new, you need to unlearn something you knew well. But it's important to recognize that if you're not actively learning and growing with a platform, framework, or code base, then you're actively unlearning it.

What are you un-learning today that you shouldn't be?

Understanding Trade-offs In Software Development

I've worked in the software industry for a decade and a half as both a software engineer and software development manager. One thing that I've learned to do for the projects my teams work on is to anticipate and understand the possible trade-offs you're going to have to make downstream.

It's a given that something is going to change between the start of a project and when you actually ship that's going to force you to make a trade-off. As I've talked about before, Agile and LEAN allow us to mitigate the cost of making these changes by reducing the time it takes to get and incorporate feedback.

One thing I haven't talked about is how to make the right trade-offs for your product.

Minimal Shippable Product

Understanding your minimal shippable product is the foundation of any trade-off decision you're going to have to make. I'm not taking about a gut feeling about what you're customers may want. I'm talking about understanding what makes your product different.

Some questions to ask yourself to identify the minimal shippable product:

• Does the lack of feature X put my product at a significant disadvantage in the market place I'm entering or are already in?
• Will 80/90/100% of my customers use feature X?
• Will missing feature X make you look stupid? For example, a text editing product without copy/paste or an image processing app without the ability to adjust contrast. 
• Is feature X a key differentiator for my product?
• Can your customers achieve feature X in some other fashion? 
• Does missing feature X cause significant friction for your customers?
• Is feature X on the short list of reasons to buy your product?

Time To Market vs Feature Complete

Another very important thing to consider is how important is time to market vs feature completeness. Are you providing a service that no one else currently provides? Does the market you're entering have a sales cycle that requires you to make a specific date?

Being first to market has strategic advantages that cannot be ignored. But being first to market with a sub-optimal product may hurt you worse than not being first. Apple wasn't first to market with the smartphone, but they offered features that weren't available anywhere else. The converse is also true though, they were first to market with the modern day tablet and it took half a decade for anyone else to really break into that market because there wasn't a compelling enough reason to buy the alternative to the market leader.

Breadth vs Depth

The last major trade-off to consider is whether your product provides a breadth of features which are mostly polished or a sub-set of those features that are fully polished. I'm not talking about your minimal shippable product here. I'm talking about the things that didn't make your MSP list, but may be the right things to build for your customers. For example, if you're providing a parity product, you need to know how much parity you need to achieve to be relevant to your customers.