by David Ogden
Over the last 30 years, our ability to create and distribute interactive experiences has transformed from nonexistent into a robust ecosystem of platforms, development tools, and distribution channels. With all the progress we have made, one thing has remained constant:
Creating, distributing, and growing software products is anything but an elegant process.
There are many methodologies, processes, and systems that are designed to eliminate common software development challenges like scope creep, quality deficiencies, and integration friction. In the end, virtually all software projects suffer from at least some of these, as well as many others.
In my experience, one of the best ways to mitigate these ubiquitous forces is to make optimization for project stage your guiding principle.
For the purposes of this writing, I’ve broken the software product development lifecycle into three stages:
To illustrate, I’m going to create a simple matrix that shows how competing priorities of a project can be shifted as the project moves through these stages.
When you first set out to build a new software product, a common mistake is to try and optimize for every factor. The classic blunder to optimize for scalability from the very beginning. While no rule applies universally, it’s relatively safe to assume that developers creating a product that doesn’t have any users yet should not be spending a lot of time worrying about scalability.
So how do you know what to optimize for, in each stage? This three-step approach is a good place to start:
- First, understand how the various demands of your project compete.
- Next, understand your project’s objectives and constraints at each stage.
- Finally, you can prioritize your demands based on your specific objectives and constraints.
Understanding how demands compete.
In software development, there is always a give and take:
Features and functionality compete with user experience. The more features you add, the harder it is to make your software intuitive. This doesn't mean the right answer is always to have fewer features (although I’d chase that feeling if you have it). It doesn’t even mean that software with many features must be complicated. But those two demands inherently compete with one another: the more you want of one, the harder you’ll have to work to keep the other in check.
Iteration speed competes with testing, QA, and reliability. Want to ship faster? Go ahead. But the amount of work you have to do to retain any given level of reliability directly corresponds to how much work it takes to create, integrate, test, and publish new code.
Scalability is the real monster. It competes with almost everything. Want to support internet-scale users? Good luck keeping the user experience real-time and snappy. Have hundreds of thousands of daily active users? Have fun rolling out a new version that keeps everyone connected without a hiccup across dozens of platforms and hundreds of popular devices.
Every optimization we make in software development comes at a cost. Embracing how demands in software development compete is what enables us to make smarter decisions in project optimization.
Understanding objectives and constraints at each stage.
Evaluating our objectives, our team make-up, and our cashflow situation at each stage of our project will help us correctly prioritize competing needs.
In the idea stage of a project, you don’t know much. You know what you think will happen. But only time (and work) will tell.
- Do people actually want or need what we think they need? Do we really have what it takes to create it and deliver it?
- What will our team look like in the idea stage? Am I a solo developer with an idea? Will we hire a few people to help us, or hire an agency?
- How much money do we have to start with?
When you arrive at the iteration stage, you should know quite a bit about the software part of things. You should know, in general, what users want and need and have some idea that you can deliver it. Now you’re asking:
- How much will people pay for this? Will they pay at all? How does that compare to how much it costs me to create, maintain, and deliver it?
- What features are missing? What features do we need to figure out how to get rid of without disrupting our existing customers?
- What features are broken? What features are underutilized?
- How has our team changed? Are we still solo? Are we adding a lot of programmers or designers? What about salespeople and support staff?
- Where are we going to get the money we need to continue to tinker with the product and prove the product and market are ripe to potentially scale?
Finally, we make it: growth stage.
We know we can build it. We know they will buy it. We know it’s profitable.
Now it’s time to focus on injecting investment dollars into marketing and sales in the hopes of creating a lot of value for our software company. New questions arise:
- What new technical and logistical challenges are we facing in scaling our software product?
- What kind of team organization do we have in place to handle the various needs of maintaining and distributing our software product?
- Do we have the money to invest in marketing and sales while also paying our developers, designers, project managers, and support staff to keep the product running?
Being able to answer these questions as you move between stages, in combination with what you know about competing demands in your project will enable you to prioritize those demands at each stage.
Strategically prioritizing demands based on objectives and constraints.
It’s time to fill in the blanks. Each project is different. Varying factors are important (or unimportant) at each stage.
Even the stages of a project can be broken down in any number of different ways, depending on objectives and constraints.
If you look at our generic example, you can see how competing demands can be prioritized and optimize at each stage:
Idea stage optimization
Most projects will go better if you focus on as few demands as is possible in each stage. Even if you had the budget to hire the teams required, the pitfalls that arise from trying to optimize too much, too soon, will undermine your project.
During the idea stage, your focus should be narrowed to:
- Creating features and functionality you believe users want and need.
- Testing your features and functionality often with potential customers.
It’s common for project owners to limit the release of the product, even for beta testers, until it has met a certain threshold of features, user experience, and QA. The problem with this approach is that software development is an iterative process. If you’re only focused on a single launch where everything will be ready, you’re not building up your ability to iterate. This is a missed opportunity.
Successful software products are created by developers who are constantly getting better at shipping the right code frequently. You can’t do this if you’re working on a launch that's months away. On a fledgling project, code should ship weekly (or more often) into the hands of real users.
There are other benefits of focusing solely on product iteration. When you deliberately choose not to worry about scalability, accessibility, and even fundamentals like user experience… it’s easy to cut right to the core of your product value.
Features and functionality that are made available through a less-than-perfect user experience can be an effective litmus test for the true value of your offering. When users genuinely want something that they can’t get somewhere else, they will put up with almost any experience. When users don’t really care, they will look for any excuse (often citing experience) to reject a product.
In the long term, of course, we want to offer both. But in the idea stage, it’s all about proving that the features and functionality we’re delivering are actually valuable.
Iteration stage optimization
Pressure starts to mount during the iteration stage. While it’s tempting to go all-in, I highly recommend that you continue to restrict your focus.
For most projects, the need to continue building out features and functionality will persist through this stage. You may have achieved some level of product-market-fit during the idea stage, but now you’re trying to figure out how to sell your product and make it profitable. This will require you to continue the process of creating new features and functionality, and testing the results with your customers.
Since you’re now trying to sell your product, not just test if users want it, the need for a good user experience will become more and more important. Creating a good user experience, like so many facets of software development, is a process of discovery. If you’ve put the effort, in early your project, to get good at shipping code frequently, it will pay off in this stage.
The ability to iterate fluidly enables you to test more ideas, with more users, in less time. As smart as you, your developers, and your designers may be… oftentimes no one can know, for sure, what will be received as good, better, and best by your users. You can only get there by iterating with real users.
While QA and testing could be put off until the growth stage, it’s usually best to start implementing them during the iteration stage. There are many reasons for this:
QA and testing add overhead to your integration process. The longer you wait to implement them in your process, the more painful it will be. Some projects actually miss the window of opportunity to add QA and testing. By waiting too long, your project can get so out-of-control that implementing QA and testing can seem nearly impossible.
Another reason to add QA and testing in the iteration stage is that they are closely related to user experience.
As your project grows, everything you change or add has the potential to adversely affect everything that came before, sometimes in very unexpected ways.
You may spend weeks creating, testing, and polishing Feature A, which your users love. Six months later, when you’re working on a new feature that is completely unrelated, you’ll write some code that breaks Feature A.
Without QA and testing, you might not know about the bug until your users start reporting this to you. Your users can only handle a limited number of bugs like this. Any users who are on the fence will jump ship at the first sign of glitchiness.
In the idea stage, it’s ok if you lose some users because your product isn’t perfect. But the iteration stage is all about closing every gap in your product so that users only have reasons to stay.
Growth stage optimization
The growth stage is where your software company really transforms from a lean machine into a force of nature that has a life of its own.
As painful as it was to put off important aspects of your software like accessibility, scalability, and performance… it’s going to be just as painful now to stop working on features and functionality. Likewise, it will be difficult to watch your iteration cycle go from days to weeks, and sometimes even longer.
The more active users, systems, and connections your software has … the more important it will be to retain the experience your users have come to expect, the value your reps are accustomed to selling, and the product your support staff is trained to service.
In some ways, it might feel like no fun to move to the growth stage. This is often the stage where the founders hand the reigns over to new management that specializes in growth.
This stage requires a different type of discipline than previous stages. If you built things right and got to the growth stage, building new features and functionality will be very difficult. For mostly good reasons, everyone in your organization will be looking for reasons to shoot down ideas for new features.
At the same time, successful software projects in the growth stage are always in dire need of more QA, more testing, more accessibility, more scalability, more performance, and more reliability.
There’s no single, correct answer.
The more you work on software, the more you will learn that every project is unique. No platform works for every job. No methodology solves every problem.
Adhering to simple, proven principles will put you in the best position to achieve success.
When it comes to juggling competing needs in a software project, the principle to follow is: optimize for product stage.
You can accomplish this by seeking to understand the demands of your project, knowing your objectives, and recognizing your project constraints. That knowledge, combined with a healthy dose of discipline, will enable you to plan and execute a development strategy that will carry you through from idea, to iteration, to growth.
