Cornerstones of Every Software Project: Part 1 of 2
(AKA: Keys to Building Amazing Software)
Software is squishy. It’s an engineering discipline unlike any other. Software is like building a bridge where the materials are unknown, the river you are building over is constantly changing course, and the laws of physics could reverse halfway through the project. Without a firm foundation, product teams cancel about 19% of software projects before completion. A staggering 47% are over budget, behind schedule, or fail to meet the expected quality standards. With the odds stacked against you, how can you possibly expect to succeed?
No matter what problem you’re working to solve, there are key elements to every software project. These ideas and practices lay the foundation upon which every project can stand, increasing its probability of success. We call these key elements the cornerstones of software development.
Why “Cornerstone”?
Historically, a cornerstone was the first block laid in the foundation. This block served as the reference point against which all other blocks were positioned. If the first stone wasn’t set correctly, the foundation and entire structure would be out of alignment.
Software is similar. The foundation must be laid correctly or the entire project could be at risk. You can always build software on a weak foundation (and many companies do). But, as soon as the system is stressed, the cracks start to show.
How many times have you felt like your team spends more time fighting fires than building real features? Ones that actually provide value to your customers. This is one sign of software on a weak foundation. A foundation where key cornerstones were missed.
Setting the Foundation
When Phase 2 starts a new project, we inform our clients it takes at least 6 weeks of groundwork before we begin working on the first product feature. We place high priority on ensuring the appropriate foundation is in place before writing the first line of code. In fact, product teams should spend a considerable amount of effort at the beginning of a project. This helps ensure all of the effort put in later is as effective as possible.
So, let’s break that down. What makes for a solid foundation when planning a project? What does it look like for a team to spend hundreds of development hours laying the cornerstones for this foundation? How does that end up providing a superior experience to your customers and, ultimately, your ROI on this project?
Cornerstone #1: Understand The Problem (Features can Come Later)
It may sound silly, but the first thing we do before starting any project is to understand the problem. All too often devs write the first lines of code well before identifying the core problem. This is the first cornerstone of software to set before building – understand the problem you’re trying to solve.
It’s easy to fall into the trap of thinking in terms of features. I want this piece of software to do “x”, “y”, and “z”. For example: an app that builds pizzas, that’s a customer billing portal, and an inventory tracking system. These may describe the idea in your head however, they aren’t problems. They are features.
Features feel good. They’re easy to talk about. You feel a sense of progress as you cross off each feature one by one as the project progresses. But, a long list of features is a sure-fire way to build software that does a lot of things. But, it won’t actually solve a problem.
The Problem Statement
Software exists to solve a problem. Example: tracking inventory on paper is inefficient and error prone. That’s a problem. This problem has to be at the center of the entire project. Start with a problem statement like, “we need a web based application to track inventory.”
Without a clearly defined problem to solve, developers can easily start tacking on features that have no relevance to the problem. The very one you were trying to solve in the first place.
Having the problem at the center (instead of a feature) is a subtle shift. However, it makes all the difference in the world. As the team considers new features and priorities, they should weigh those against the problem statement. You can more easily decide how critical a feature is by asking if it actually solves the problem at hand. A web-based application to track inventory can have a lot of features with nothing to do with the initial problem. Remember in this example, it is “tracking inventory on paper is inefficient and error prone.”
Understanding your customer and their problem is what should guide the entire project lifecycle. Furthermore, if the customer or the problem shifts, the project has to be able to shift with it. It’s much easier to keep a pulse on this if your focus is constantly on the problem statement.
Focusing on features is how you end up being unable to see the forest for the trees. Feature lists lead to scope creep and blown budgets and projects that never make release dates. However, problem-focused teams build focused products that solve real problems.
Cornerstone #2: Keep an Agile Mindset
Have you heard of Burbn? It’s one of the largest social networking sites in the world. If not, you might know it as that little app named Instagram. Their start-up story is fascinating. It is one of the best examples of what can happen when you keep an agile mindset and allow real-world usage to drive your product decisions.
Two years before Instagram was a billion-dollar Facebook acquisition, it was a start-up known as Burbn. Back in the early 2010s, location-based apps were hot and trending. The Burbn founders’ had the idea of being able to post a picture of your current drink and tag where you were drinking it. This idea was enough to get the attention of venture capitalists and close a seed round.
The founders quickly found users were mostly sharing pictures of their lives, not just cockails. The location-based features and the social-drinking aspect weren’t all that important. Rather than try and find a way to force these features on users, they were agile and quickly pivoted into what launched shortly thereafter as Instagram. The rest is history.
Putting Your Users in the Driver’s Seat
It’s easy to lose yourself in the grand vision of the software project’s end state before focusing on user needs. If the team is not keeping those top-of-mind, developers can fall into the trap of testing and tweaking until a release is “perfect”. What’s actually hard is releasing features in small increments then allowing user feedback and real usage data to drive your product roadmap.
The concept of building software with an agile mindset is about so much more than “backlogs” and “sprints”. The heart of this project management philosophy often gets lost in all of the terminology and ceremony surrounding “agile” or “scrum”. At the end of the day, it’s simply about focusing on what is currently the most important thing and being able to quickly pivot when priorities change.
Think about your feature backlog and ask yourself, “what feature on this list can provide immediate value to our users?” Focus on releasing that feature to the world and watch how your users respond.
It doesn’t matter whether the initial release bears any resemblance to what you’ve envisioned for the final product (it most likely won’t). What matters is you’ve released something which provides value to your users and it allows you to start gathering valuable feedback to drive future decisions as you continue to grow, refine, and re-prioritize your backlog. Furthermore, this process naturally leads to faster release cycles giving you the opportunity for an iterative development process where you can constantly adjust the path of the project to provide the most valuable features now.
This kind of agile mindset puts you in a place where you’re not only delivering features, but actually solving the problems your users care about. Imagine if the founders of Instagram continued down their initial product roadmap centered around social drinking, never shifting priorities based on how users were actually using the app. Not only would they waste a tremendous amount of effort on features their users don’t value, they most likely would miss their window for turning it into the incredible success story it is today.
Identify Problems, Implement Solutions
Our first two cornerstones deal with the heart of what custom software development should be, identifying real problems and building the most impactful solutions. If you can’t identify the problem, you can’t implement the right solution. And the “right” solution isn’t always immediately clear. It is critical that the team focuses on the highest priority issues with a willingness to pivot as feedback is collected and priorities shift.
In part two, we talk about how the concepts from these first two cornerstones fit into the real world where timelines and budgets always feel too small and project scope continually wants to grow.