Building a successful software platform

Building a successful software platform is done by building software with a purpose by solving a problem that people already have. The problem may not be obvious, and it may not even be a problem that people are aware of, but the problem exists. Using Instagram as a case study, I think there are four keys a platforms success.

Intrinsic Value 

Most people aren't professional photographers. They don't have access to the tools professional photographers use nor the time or money to buy the tools and learn them. But they do want professional looking photos. Instagram built a platform that had intrinsic value on it's own by providing people the ability to easily create professional looking photographs.

Simplification

One of the keys that made Instagram successful was that they took something people were already doing and made it easier and better. They removed the need to download photos from a mobile device and then upload them from a desktop or laptop. They simplified the process and allowed users to share exiting photos right from their phones or take a new photo to share.

They also simplified an otherwise complex photo editing process by providing a set of templates that people could apply without having to understand image editing. This enabled a regular person to have professional looking photos without any work.

Interoperability

One thing that Instagram did very well is that it built it's software to work with exiting services like Facebook and Twitter. Services that already had a huge community of users. They didn't try to re-create Twitter or Facebook. Instead, they allowed Twitter and Facebook to get better by making their service interoperable.

Choice

Instagram didn't force people to ONLY use their service. Instead, it allowed people to continue to use their existing social media services and augment a specific workflow to be better if they wanted to. Users don't want to be asked to chose between this OR that. They want to be able to use this AND that. Will your software provide additional choices or limit choices?

Improving the efficiency of your team: cleaning up after yourself

If you're anything like me you're constantly trying to figure out a way to help your team become more efficient. One area that's often overlooked is how much time your team spends repeating the same mistakes or cleaning up after the same mistakes over and over again. I'm not talking about show stopping, bring your site down mistakes. If you're having those often you've got major problems in your underlying infrastructure and you should stop all feature development and get it fixed right away.

No I'm talking about small mistakes that over time compound the amount of time your team is taking to work around a problem or clean up after it. In order to help your team spend more time working on features and less time working on cleaning up after mistakes you should be doing two things.

Retrospectives

I've written before on Sprint Retrospectives before but it's worth mentioning them again as they are the easiest source of improving the efficiency of your team. Sprint retrospectives are a good way to understand what's randomizing your team. They're also a good way to find out why your teams estimates were off (i.e. what wasn't accounted for or what was over accounted for).

The key to the sprint retrospective not to just talk about the problems, but to create action items that will resolve the problems moving forward. After each sprint retrospective you should have an action item list. Each item in the list should have an owner and a due date. This will help ensure that nothing falls through the cracks.

Postmortems 

Postmortems help your team identify and correct problems with your process or places where there is no process where there should be. I wrote a good deep dive into postmortems a while ago, but the key to a postmortem is that you use the facts about an incident to see where your process breaks down and identify clear actionable steps to prevent the breakdown in the future.

Postmortems don't have to be used when something catastrophic happens. You can use them to help identify simple things that prevent your team from being more efficient. For example; you can do a postmortem on your sprint planning if your team wasn't able to accomplish all the work they scoped for the sprint. You can do a postmortem on why a feature wasn't built as expected or why a build broke. You can do a postmortem if your team misses a date. There are many reasons you can do a postmortem that don't have to do with a catastrophic event.

The goal is not to do a postmortem for the sake of doing one. But instead to add value where possible by identifying areas of inefficiency and digging in to find out where the problems are and creating actions to remedy them.

Two questions you need to ask yourself everyday to be successful

There are two questions that I've learned to ask myself (and others) everyday. Two very simple questions that will help you to uncover a lot of bad habits and help you fill any gaps preventing you from accomplishing your goals.

1. What am I doing today, that if I stopped doing, would be beneficial to me or my team?
2. What am I NOT doing today, that if I started doing, would benefit me or my team?

What you need to stop doing

The goal of this first question is to help you look more objectively at yourself, your habits, and your process and find roadblocks that you're putting up yourself. There are many many many things that every one of us does everyday that get in the way of us being more productive. The key is identifying them and either replacing them with something helpful or just stopping the behavior all together.

For example, are you randomizing your team without knowing it? A good example of this is asking a question of your team that causes some of them to stop working on what they're working on to get you the answer. Are you sure getting that answer now is a higher priority than what they were working on? If not, that's something to stop doing.

There are so many examples of things we do every day from the emails we send to the meetings we call that are not helping us or our teams be productive. Rooting out these problem behaviors/activities will help you and your team be more productive.

What you need to start doing

The goal of this second question is to help you identify your blind spots. I can promise you there are several things you're unaware of that happen everyday that, had you been aware of, would have changed something about your work. Your goal should be to help identify these things and incorporate their knowledge into your everyday process.

For example, maybe your team suffers from randomization, always being pulled in a different direction. You need to start saying no to work and work on creating an intake process to help prioritize your current and future work.

Like the former question, asking this question will help you understand your problem space better. The better you understand your problem space, the easier it is to navigate and be successful in it.

Stumped where to start?

The great thing about these questions are that everyone around you has an opinion on them.  Start by asking your boss and your direct reports these questions. I would bet that you'll be surprised at some of the answers you receive.  Beware of those who constantly answer "nothing". They're likely not invested in your growth or the growth of your team.

Are you using your own products?

I'm always surprised when I work on a software team that doesn't use the product they're building. It's a sign that your team isn't invested in the product. More importantly, it's a sign that your team isn't as invested in the customers.

Teams who dogfood their own software make better products. That sounds anecdotal, which it may be, but that's what I've seen in practice. Why is software better when those that make it use it?

Your team is always in the ecosystem

If you aren't immersed in the ecosystem that your app lives in, you won't ever truly understand how your app should work. You won't understand what metaphors are the right ones and which ones will feel foreign or fake. You can be sure your customers will notice if you use an iOS metaphor on an Android phone or a Windows metaphor on a Mac. Until you are immersed in the environment your customers are in you won't really understand your customers as well as you could.

Your team is your customer base

Relying on your own software in your day to day life builds empathy for your customers because you are part of the customer base. You'll find the workflows that need simplifying. You'll understand which features are missing. You'll cringe and curse every crash.... just like your customers do.

Your team feels any added friction

When your team is using your app you discover added friction before your customers do. For instance, if you make a change that's not backwards compatible, your team will find it first because they're already using the app and that feature. Add additional, and unnecessary steps to some workflow, your team more likely to find it than a paying customer.

Long and short, you find the mess in your app before anyone else does. When the app gets to your customers, they're delighted with how intuitive your app feels.