We spend all of our time discussing software on this blog, so it's high time we take a closer look at how software products are actually built. Building software products, like any vertical, comes with its own unique set of challenges. In this post, we'll demystify the software development process and talk through what it takes to build and deliver software. By the end you may begin to understand why large software companies have tens of thousands of software engineers on staff.
Building a team
Software companies tend to be organized differently from other businesses. It starts with software engineers. Software engineers generally build off of the same foundational skills. From there, however, you’ll find myriad specialties to dive into. Those specialties are constantly evolving. New ones appear and others fade away. Every day it is harder for any one individual to have enough depth of knowledge in every critical area. For example, while the same app on iPhone and Android may look and feel identical, under the hood they are completely different.
Depending on the complexity of the project, you may need:
Front-end engineers, who focus on the user interface and user experience, the piece that your customers will see and use. This is not design, this is the actual functionality. If you click (or tap) a button and the screen responds or changes display, a front end engineer wrote software to enable that.
Back-end engineers, responsible for the behind the scenes stuff. Let’s say you submit a form. That form goes to a server, gets processed, and you get something back. A back-end engineer is responsible for that processing logic. The front-end engineer makes space for that response, and separately a designer makes it all look nice.
Full-stack engineers, who are capable of working on both front-end and back-end tasks. These role players bridge the gap between the first two teams. Full-stack engineers are kind of like good, all around athletes. They are invaluable on smaller teams. As engineering organizations grow, however, the tendency is to hire more specialists.
Mobile engineering mostly means Android or iPhone/iOS. To us end users, the devices function largely the same, but behind the scenes the operating systems have totally different philosophies. The two systems have entirely different processes for how screens show up, notifications work, and so on.
This list could go on with DevOps engineers, Quality assurance engineers, Data engineers, Security engineers, Cloud engineers, and System architects who all play critical roles, particularly in large software organizations.
For all the specialties, software engineers alone won’t get you a complete product. Left to their own devices, engineers will build something interesting and amazing. Which means it will be amazing to other engineers. It’s incredibly unlikely they will make something a non-engineer can understand, let alone use. I say this as a former software engineer myself, software engineers need to be corralled, organized, and pointed in a specific direction. Sometimes it's just as important to identify what not to build. That’s where the rest of the team comes in.
To steer the development process you need product managers (PM). For smaller companies, this tends to be the founder. These people must have a clear vision of the problem we’re trying to solve and how to bring it to market. The PM deals with the “what” and works closely with software engineers to ensure the product aligns with the intended vision.
Designers play a crucial role in shaping the product's appearance and user experience. Their job is to make it as clear, obvious, and hopefully delightful what you can do in each screen or view of the software product. Part art, part science, all difficult. You won’t know good design when you see it, but you will know bad design.
Beyond that core software development team, a software company needs what every other company has too. Marketing, PR, sales, customer service, finance, etc. While these are traditional sounding roles, they do come with the added burden that any good software product is always evolving.
Building a product
Typically the first milestone for any software product is creating the Minimum Viable Product (MVP). This is a scaled-down version of the product, designed to test its functionality and ensure it meets basic user requirements.
It’s the PM’s job to define what that MVP should do and quite possibly their job to design it as well. The engineers building the product will be faced with critical technology decisions every step along the way. For example, if we are building a product that has to work for millions of people at the same time, we want to use sets of technology that the industry has taken to calling “hyperscale.” This technology, however, is quite useless, and sometimes performs even worse, when you have less than 1000 people using your service. For an MVP you might only have 100 users. In other words, when you’re just getting started you’ll be using more standard components.
This conscious technical trade off creates “technical debt.” It’s debt in the sense that it must be resolved, or worked around, at some point in the future. Teams take on tech debt in order to deliver the product faster. If you’re building a highway or a city, you have to plan for how many people may live there before people live there. With software, on the other hand, you can rebuild the system while people are using it.
Building your MVP means bringing together the A-Team, but for software not secret missions. You need a PM and a few full stack engineers. Ideally those engineers have some mobile experience as making your app mobile ready is table stakes today.
Launching a product
Now let’s grow our product so we can have some of those “scale” problems. In order to do that we have to find Product-Market Fit (PMF). Sometimes you’ll hear people say the team must “go to market.” This may mean a targeted marketing campaign or personalized outreach to potential customers. Feedback from your desired audience is invaluable at this phase. Are they finding all of the features of the software? What feature are they using the most? The least? Are they coming back to use it again? If this is business software, it’s important to find out if people are willing to pay for it.
All of these questions are designed to create feedback loops. Feedback loops are essential in the software development process. As people engage with the product, the team must analyze their behavior and adjust the product accordingly. Software products are constantly collecting or creating new data that answers these questions. Loyal readers of our blog may see a pattern here. We advocate for a software defined business engine to increase productivity and give you data to build your own feedback loops.
In a software company, a key part of the PMs job is analyzing usage data and feedback. Usage data is data “coming off of the product.” It tells a story about what people are actually doing with your software. For feedback, companies may create surveys, or conduct user studies to collect any qualitative feedback. Great PMs are able to identify bottlenecks or growth opportunities to further increase usage of the product.
These new ideas are then turned into features which the software engineering team builds out and releases. The data is monitored, and compared to previous data, to determine the impact of the change. A well functioning software team is constantly building on successes, learning from failures in aim of continuously improving the product. Side note, this constant release process is the foundation of the SaaS model.
Success and Scaling
In the early days the team should be able to move quickly. Feedback and management insight can guide a rapid pace of development until you find sustainable PMF. Once you have a consistent, reliable business the organization will naturally have inertia to change. Sometimes feedback or even an insight will be a significant diversion from the planned course.
Scaling, of course, means new customers. It’s very likely these will be new types of customers you hadn’t originally identified. Balancing your product to fully service these new customers while keeping your original customers onboard from a business perspective is one challenge. On the technology side, the software team must manage branching product development, deal with technology limitations, or addressing technical debt. Teams have to juggle this while maintaining service quality.
This is typically the stage where small teams start to hire more specialized engineers. You might hire engineers who can handle the new problems or more engineers to help manage the technical debt so the core team can keep building. As you scale to thousands of users that technical debt could inhibit future growth, or actually cost the business money with downtime or outages.
Experience and good management will stand out at this stage. Skilled technology executives work tirelessly to maintain a high pace of development while ensuring quality and customer satisfaction. The management team has to address the near term challenges and ensure the team stays on track for the long term goals.
Hyperscale
Every software company is aiming for hyperscale. This is the scale where millions of people are using your service. Hyperscale presents its own, entirely unique sets of technical challenges.
Take for instance, logging in to your favorite website or app. Whether that’s Snapchat, Instagram, or Netflix every time you fire it up, the software on your device has to talk to the software on the company’s servers to make sure it’s really you before it even figures out what to show you. In some cases you might have to enter your password again.
Password or not, if you’re a user of any of these apps you know how quickly you can go from tapping on the screen to seeing your personalized home page. That means the software on your device (client side) and the company’s software (server side) confirmed who you are (authentication) in probably 0.05 seconds. It all happens so quickly it’s easy to take for granted the complexity of what’s happening behind the scenes. At any given moment in time, tens of thousands of people (or even hundreds of thousands) are logging in to one of those services concurrently and it takes some incredible feats of engineering to ensure this happens seamlessly, without disruption (at least most of the time).
When these teams were building their MVPs they likely started with a straightforward queue for any requests from the client side. In fact, it’s surprisingly straightforward to have that speed out of the box when dealing with a small number of users. You can just “queue” any requests to the server. That queue will move as fast as physically possible.
This decision created some technical debt. That’s because this type of linear queue becomes a bottleneck when you start to reach scale, say in the tens of thousands of people. If, at this point, the server is still taking each client request and processing it through one queue, the software will feel slow. People will start to leave the app faster than our queue is processing their requests. This will directly impact the business bottom line and clearly this is an unacceptable outcome.
Ideally the software engineering team is aware of the technical debt and can redesign the queue before it becomes a bottleneck. Done well, the people using the app don’t notice anything has changed. This is why companies growing the way that Google, Meta, and Snap have grown are constantly hiring more and more specialized engineers. As usage of these services skyrocketed, to a user any issue probably looked the same. Meanwhile, backstage, the cause could be the tech debt you created or a human mistake (software bug) or other unknown tech debt.
Let’s take AppleTV for example. At the surface it’s another video streaming platform, people log in and find what they want to watch. Simple. When that new Ted Lasso season drops, however, millions of people have to be able to watch the same video at the same time otherwise you risk losing them as customers. After all, that’s what happens on regular TV.
These types of exponential, hyperscale growth problems manifest in slow or bad service quality. Hyperscale companies organize the engineering teams differently such that they can each focus on local solutions that, together, improve the overall service. In fact, as they grow they will add internal engineering teams whose sole job is to ensure the various product engineering teams don’t release code that conflicts with one another potentially crashing the site.
Getting Started
If you're considering building a software product and you don’t have a deep network of software engineers, don’t worry! There are plenty of options available to help you find the right team. But first, are you building an app for yourself or your business? Or are you trying to build something you want to make more broadly available?
For personal or internal business use, services like Toptal and Upwork can connect you with talented software engineers who can turn your vision into a prototype or maybe even a finished product depending on the scope.
For bigger projects, if you are comfortable doing the design and PM work there are contract software development agencies. These companies will quote out your project and build what you tell them to build. Many people with ideas and funding, start with this route and are able to build a sustainable software business this way.
The next step up in cost is staff augmentation firms that place software engineers into your company for short periods of time. The most expensive, up front cost route is a full-service development shop. This is a company that can take your idea, design it, product manage and build it from end to end.
No matter which route you take, it’s important to have a clear idea of the finished product. In the software world we call this “keeping a narrow scope.” Along the way you’ll learn many things that may influence your product direction. Any changes or new features will add cost, complexity, and time from where you started. It’s up to you to keep these tradeoffs in mind. You have to make the hard decision to stay on track or to add new functionality that was originally “out of scope.”
Last but not least, consider the ongoing maintenance and usage. When planning for success, keep in mind there will be tech debt that slows you down along the way.
Building a software product is a challenging but rewarding endeavor. We hope that understanding the process will help you make better informed decisions on your journey. While the reality is very complex, the good news is that in many cases you can focus on just being a good software buyer instead of trying to develop it yourself.
Comments