How to make software products the smart way

Poornima Vijayashanker is the founder of Femgineer, helping entrepreneurs and tech professionals (especially women) level up their careers.

As technologists, we want to build software that is friendly, fast, beautiful, responsive, reliable, secure, and scalable. And we expect ourselves to deliver it on time and under budget, because our ultimate goal is to have lots of happy customers who can do what they want.

But time and energy are finite, and we simply cannot deliver it all at once. We need to choose our priorities, and this choice is one we should make consciously.

Evaluating our software development priorities while dealing with constraints is known as the tradeoff space, and is influenced by:

• Your technology stack
• Your business model and customer needs
• Cost of a mistake and a company’s appetite for risk
• Onboarding employees

Want to make smart tradeoffs when developing software products? I recently interviewed Jocelyn Goldfein, the former Director of Engineering at Facebook, to talk about the tradeoff space and how to evaluate your priorities.

Start with your technology stack

Where does your software product sit in the technology stack? Its place in the hierarchy can impact the kinds of tradeoffs you can make. “Different technology stacks lend themselves to different solutions,” Goldfein says.

For example, if you’re building a web application, you’re at the top of the stack:

• This gives you the freedom to build quickly by reusing a lot of existing libraries and frameworks. You don’t have a lot of control over them, but you’re saving a lot of development time.
• You can also deploy your application to your own servers or a managed hosting provider. Regardless of which you choose, web servers have similar environments, so you don’t have to worry about device-level variability.
• Bug fixes are a cinch! Since you control when you deploy your web application, you can make fixes and updates quickly and frequently.

As you move down the stack, you don’t have as many libraries or frameworks to build applications quickly, but you have more control of what the application does.

For example, if you’re building a native mobile application, you have access to the device. Unlike a web application, your app can use the device’s camera, the accelerometer, and interesting metadata like the user’s exact location.

But you don’t own the deployment environment. A third party has to certify your application before it can be released to users, and, “you have to think differently about how frequently you can update,” says Goldfein.

Next, factor in your business model and customer needs

It’s easy for us to make tradeoffs based on the limitation of our technology, but as Goldfein says, “it’s not a technology-driven decision alone.” We need to think about what matters most to customers and what their expectations are for your product’s benefits.

We get really wrapped up in thinking that a product’s benefits are based on its features, but Goldfein argues that benefits are actually driven by your business model.

For example, when building enterprise software, reliability is a key benefit. If a product isn’t reliable, then it can impact the bottom line of your customer’s business.

Contrast that to consumer Internet applications: reliability is less crucial as a benefit, because consumers usually don’t need to use an application (but they should want to). . So instead, it’s important that the product is compelling and the users want to use it. This is one of the reasons many consumer Internet applications prioritize user experience over things like reliability or high up-times.

Ultimately, it doesn’t matter if your tech stack has the capability to do more, if that’s not a top priority to your customer.

“We have to be motivated by the person using our software. We have to remember that we cannot do everything in the world we’d like to do, so we should do what matters most to that person. When we design for the person, we do our best work,” says Goldfein.

Weigh the cost of a development mistake against your company’s appetite for risk

“It’s easy to think of appetite for risk as a character trait or a moral quality. But it’s not,” Goldfein tells us. She continues, “We think it’s just about philosophy or [founder] personality.”

As she puts it, risk comes down to asking yourself: “If you make a mistake, what is the cost to fix it? And what is the pain to my customer?”

But there are real reasons why some companies have a greater appetite for risk than others.

It goes back to the two dimensions of technology stack and business model.

If you’re building a web-based consumer internet application and you introduce a bug, there’s less pain for the end user, because they have a want-to-use mindset. You can also quickly fix the mistake. Hence you have the freedom to make a lot of mistakes without jeopardizing your business..

But as you move down the stack, the cost of fixing an issue goes up, and the pain to users goes up.

For example, if you are building systems-level software like VMWare and you introduce a bug you cannot easily deploy a fix like you can with a web application; you often have to get third party approval. This takes time and resources, which hurts your end user and shifts your team’s focus away from other activities. So if you’re building systems-level software, you have to prioritize having a careful process and testing before your release.

Onboard new employees so they know your values and tradeoffs

The last thing you want is two leaders to make tradeoffs that cancel each other out.

When you bring in leaders, you need to be conscious that they come from a background that emphasizes the same values as your organization. Even if the new hires come with a different set of values, that’s OK. It’s more important that they can adapt and you can onboard them thoughtfully.

To hear more from Jocelyn, watch the interview on Femgineer TV.

Read Next: Being a manager doesn’t make you a leader