Custom Software Consulting & Development

1.347.674.6277
hello@rapidapplabs.com

Building a Better Product, A Developer's Perspective

by Thomas Lackemann Posted on Aug 29, 2016 in

Great products are built by people who are excited about the problems they’re solving and know why they’re solving it. Sometimes products are created based on luck, and more-times-than-not, they’re not. Behind each great product is a team of software engineers and product owners who work hard to ensure its continued success.

When it comes to building products people love, what can we do, the software engineer, to help ensure a product’s success? In this article I want to talk about how a product’s success is ultimately held in the hands of the software engineers and how better methodologies in developing will in turn lead to better products for users.

What’s a Product?

When software engineers talk about building products, we normally talk about the components that make up the product. We talk about the database schemas, APIs, hardware, frameworks, orchestration, concurrency, SLAs. Rarely do we ask why we’re building a product. Most of the time our job is to make the product happen no matter how challenging the specifications might be. We’re not paid to ask questions on product implementation, we’re paid to build the software that makes it work. Our pay is directly tied to our skill to make the latter happen.

To a product manager though, a product is a living, breathing organism that is constantly being put through the most unforgiving test of survival of the fittest. The product must solve a problem that is both relevant and profitable and if not, then adapt to do so quickly or cease to exist. Product managers are paid based on their ability to make products that survive the market. Their pay, unlike engineers, is based on part luck. No matter how well the software was built it’s worthless if people don’t use it.

The Problem

According to Forbes, about 9 in 10 startups will fail because “they make products no one wants.”

There’s a lot of speculation as to why this number is as shocking as it is but I believe there’s a pattern we can focus in on, market need.

Let’s go back to engineers for a moment. Where do we tie into this? As engineers, we’re responsible for building and maintaining the product such as how changes are made, tested, and deployed. Depending on the specifications, we might have built an application that is powerful and performant but hard to iterate on. Given the specifications, it was built to do a job and to turn back and undo all that work would be tragic and counter-productive. So what happens when a manager comes in with a core product change? We give our honest estimates for the requested changes and the company will either invest more into the product to test a new segment or find a way to recover the loss.

When companies fall into this pitfall, it’s hard to escape. It’s expensive for the company to learn and it’s taxing on the engineer’s emotions (we take pride in our good work, we don’t like feeling like it was waste of time either.)

So what can we do to avoid failing?

1. Start With Scratch

Strive to build the cheapest application possible by any means necessary (including awful one-off hacks or workarounds) to prove an idea is valuable before investing any time into a product. The benefits of this are two-fold: the product is put in front of customers quickly and you gain insanely useful insights on the product before investing a lot of resources. Let’s take an example.

Let’s say your company is looking to expand its offering to a new country. Little is known about the offering you provide in this country and no one is sure if it will be successful. Instead of opting to translate the entire site into the new country’s primary language, which would not only be timely but costly, a small team of top-notch developers and product owners decide to launch a single translated landing page directing traffic to the business’s most attractive service. They measure small key events like “Call to Action” clicks and sales conversions to decide if the offering attracts buyers. This solution will take only days to setup and will have results on the success of the product before the end of the month. From there the company can choose to expand progressively into the new market or try another test to see what other opportunities might exist.

There is no easier way to prove a product’s worth than building something extremely quick and getting in front of potential customers. Not only does the business collect valuable insight about its product offerings in this new country, it does so quickly and cheaply!

It’s worth noting that this scrap test you build will be far different from a prototype (which should be built with goals in mind, more of that in a second.) Any code written for the scrap test should be tossed after the experiment is over and not be used in any way when building your prototype. While this may seem like a waste of time and trust me I’ve been there, you’ll be saving yourself a countless amount of time in the long-run (you wouldn’t build a house using the same materials as it’s scale model.) Remember to build it quick, crappy, and cheap; test and forget.

2. Build a Prototype

After proving a product’s worth, the next sequential step is to build a prototype.

Prototypes, like the scrap test, are real, functional products that are put into the hands of customers but for the purpose of measuring, collecting, and iterating on customer feedback. Prototypes that are able to iterate on customer feedback the fastest are the most likely to survive so being able to move quickly when developing is key.

It goes unsaid that moving fast and writing clean code is a rarity and it should be accepted that there will be some technical trade-offs and technical debt along the way for the purpose of shipping features rapidly. However, prototypes should still be built with far more consideration, planning and care than the scrap test. For the best possible chance of success, a prototype should be built with the following in mind:

Clearly Defined Goal

What’s a science project without a hypotheses? Much like a science project, our prototype is built to help answer questions we have. We form hypotheses, or goals, to align what it is we think we know and what we’re hoping to find out. As an example:

Hypotheses: Customers in the United States have a need for [X] and are willing to pay $[Y] for it.
Goal: Convert [Z]% of existing, US customers

Create a target that is measurable, obtainable, and realistic for your team. From a people standpoint, a goal helps align the project amongst engineers and managers. Engineers know why features are being implemented and managers know what targets they need to hit to be successful. Everyone is on the same page on where the product needs to go realistically in order to hit these goals.

Event Tracking

Event tracking is critical to a prototype’s success. Events should cover every aspect of your product and should be carefully organized in areas that define the success of the product. Events can be used to determine customer engagement, help craft better interfaces, and help answer the who, what, when, and how questions you have about your product. From these questions you can speculate on the why’s to make changes in your product to help accelerate it’s success (you can also ask your customer’s directly, but we’ll talk about that soon!)

Event tracking helps uncover patterns in the application such as, are users clicking the bright red button in the menu or are they finding an alternative way to get places? A better interface typically means users will spend less time fumbling with your product and more time using it to solve a problem.

Event tracking also helps us focus in what’s working and what’s not in our product. If a particular section of the product is not getting the expected amount of usage, consider it worth removing and wait for customers to notice, if any.

When working on collecting events, make sure to use a well-known collector such as statsd, Prometheus, MixPanel, or even good ol’ Google Analytics. Using a well-known service helps you visualize your data and observe trends in the events you collect.

Split Tests

The goal of a prototype is to learn quickly. Knowing what features are working and what aren’t takes time, effort, and money to execute. In order to speed up the learning process and keep the considered costs low, prototypes should be able to execute any number of A/B (or “split”) tests. The benefits of user testing is exhaustive but let’s cover just a few reasons you should be split testing.

New features can be released to a certain percentage of users and measured for engagement. Utilizing event tracking, the prototype should be able to measure how each test is performing in real-time. Releasing to a percentage of customers gives product owners and engineers the opportunity to test radically new features and only release them to a small group of customers. If a feature is not performing well there’s no need to continue pushing it out and it can simply be removed.

Split testing also allows us to test different price points for our offerings. If you’ve considered charging more for your service to see if people would still pay for it, perform a split test! Collect sales events for each bucket, (a) those who see the normal price and (b) those who see the increased price. If profits are optimal then set your new increased price and conclude the test.

Feedback Collection

A great prototype should have a mechanism to allow your customers to leave feedback. This mechanism could be as simple as a “Leave Feedback” button that links to a form to a more interactive “Chat Now” button that allows you to chat with your customers directly.

Giving feedback should be as easy and seamless as possible for the user and it should not interrupt any workflow the user may be in (don’t pop up a modal asking for feedback.) The user should be able to give feedback from any page or screen of the application.

In my opinion, live chat is the best way to collect feedback from your customers. Live chat enables you, the developer, to hear customer’s problems first-hand. Are they having trouble finding something? Maybe they’re asking if they can do something that may not exist yet. Either way, you get to learn exactly what you need to improve on or build next. When implementing live chat for your product, make sure there’s a visible button with a prompt such as, “How can we help you?” or, “Tell us how we’re doing.” Your live chat should be staffed by developers, designers, and product owners alike in order to gain the most first-hand learnings about your offering.

Technology

Finally, build a prototype on a technology stack that is both well-known and production-tested by your team. While prototypes are great learning opportunities for developers to try new services and products, they should be built with the customer in mind. The customer does not care about PostgreSQL, MySQL, or MongoDB - the customer wants a product they can use.

Ensure your prototype also has efficient test coverage. Moving fast doesn’t necessarily need to result in breaking things. Follow a TDD, BDD, etc. standard of development if you don’t already.

A prototype is still a test. There should an equal amount of time spent developing and debugging the prototype as there is learning from your customers.

3. Evolve the Product

You’ve acquired customers, you’ve tested your market segments, you’ve learned your target audience and you’re ready to bring your product to the big leagues. At this point, a prototype is normally ready for a large marketing effort which will hopefully bring it new customers from all reaches of the world. Anything is possible with a good marketing team; new landing pages could be tested, new price points could be offered, large traffic spikes might occur.

Knowing if your prototype is ready for this new creative push is crucial. Before any large-scale efforts are made, there should be an architecture review of the prototype to ensure that there is a strategy to scale. If you’ve been keeping tabs on your technical debt the entire development cycle, then bravo, but don’t feel bad if you didn’t. Take this time to clean up your codebase and get some “quick wins” like cleaning up a frequently used bad SQL query. If you haven’t already, make sure there are alerts for your product so you can fix things quickly in case something goes wrong.

Conclusion

A prototype is an application that is finely-tuned to measure, collect, and iterate on customer feedback. Products that satisfy customer needs and generate a profit are the most likely to survive.

As software engineers, the prototypes we build should be built with careful planning, organization, and compromise. By shipping features fast and often, we ensure we’re learning the most about our customers and ensuring we’re on the right track to success. By being product-obsessed and putting customers at the forefront of everything we do, we can help build amazing products that people will actually want to use.

If you found this article useful, please consider subscribing. I’ll be writing a lot more on the subject of product development.

Cheers!

Comments