Speed of Learning Matters
How the Better Product Company builds its software
Overview
- Learning fast is more important than moving fast
- Sustainability is more important than fastest surge
- Progress is pointless without a validated direction
Introduction
“Move fast and break things.” By this point, everybody in the software industry has heard this simple statement. Whether you agree with it or not, it’s had an impact on how we build software. After a couple weeks of work at night and on the weekend, we’re about to launch our second application here at BPCO. We’ve built the product very rapidly, but the speed of development is NOT the speed we want to focus on today. Everything in our development process is optimized to maximize the amount learned, and minimize the time taken to learn. Today, I want to talk about one of the core principles that we use at BPCO and that we find tremendously valuable: rapid learning.
The Starting Line: Assumptions
Each product starts out with a handful of assumptions at its core. We may have more confidence in some assumptions than others, but a good software development process is focused on validating (or invalidating) those assumptions. Assumptions are important, and need to be clear enough to act on it. Quick examples:
- Good assumption: Most of my users will be using an Android tablet.
- Bad assumption: People will like my app.
While both assumptions can be “tested,” only the Good assumption can result in concrete, actionable information that can impact your development process. You may find that most of your users ARE NOT using an Android tablet, but rather an iPhone. With this information, you have a clear target for the next set of experiments. For the Bad assumption, most tests you run will not result in any valuable information.
At this point in the game, it’s absolutely good news to find out that an assumption is wrong. If you understand why you were wrong and have a clear idea of what to do instead, you’re in a fantastic spot to build a valuable product.
For our next product, we have a key assumption that teams and companies will soon be looking to level up their product management practice, similar to how design and engineering have seen recent evolutions. We’re assuming that product management is going to be the cornerstone for software development, and every team member is going to need to be familiar with its concepts and principles.
Ongoing Work: Get Real Feedback
We have a list of assumptions, we are putting together some experiments to validate those assumptions, and (hopefully) we have an engaged audience of potential users excited about our product. Now what? It’s simple: be relentless about gathering feedback. If you think of building great software as an expensive activity, then knowledge is your currency. The more knowledge you have in your bank account, the better your product can be. The way to stockpile that knowledge is by constantly getting real feedback.
What is real feedback? Great question! I qualify real feedback as feedback obtained by your REAL USERS using your REAL PRODUCT (or as close to real as possible). Your mother will not give you real feedback. A target user cannot give you real feedback based on static screenshots. Real feedback is key to making great decisions in your real product.
Now, this doesn’t mean that feedback from static screenshots (or from your mom) is not valuable, but it does put an emphasis on getting real as quickly as possible. At BPCO, we’re focused on getting a working product out the door by the end of 2016 so we can get our real feedback. It’s faster for us to build working software than it is to build designs and clickable mockups, so we’re going straight to the real deal. Check out www.bubble.is to see how we’re able to do that!
How to Get Real Feedback Rapidly
There’s no secret to getting frequent feedback. In fact, I’ll outline it in simple steps:
- Get a handful of real humans who might use your app
- Prioritize work that solves their problem
- Come up with the simplest implementation of those features that still delivers value
- Build the things
- Ship the things
- Give those things to your users
- Watch and talk with your users
- Repeat
We like to operate on weekly iterations (a model I learned while working at Pivotal Labs), meaning we have something new out in the wild AT LEAST every week. Often, we deploy new software as soon as we have new value to share with our users, which could be multiple times per day.
Sustainability
Sustainable Pace is a hot phrase right now in agile development circles. Actually, I don’t know if that’s true, but if it isn’t, it should be! Sustainable pace is a fancy way of saying, “Go as fast as you can forever.” Let’s break that down a bit, starting by talking about what it DOESN’T mean.
Going fast forever does NOT mean:
- Ignoring best practices
- Cutting corners
- Grinding/crunch time
- Throwing tons of people at a problem
- Quality doesn’t matter
- Working without validation
- Skipping unit and integration tests
- Not doing QA
Just like many teams use the word “agile” to mean “ignore documentation and get sloppy,” a large number of teams also use the concept of “going fast” to mean breaking process or throwing best practices out the window. Due to this, I’d like to rephrase the concept: “Go as fast as you responsibly can forever.”
Go as fast as you responsibly can forever.
The word responsibly will mean different things to different teams, but I’d implore a focus on doing things the right way. If cutting a cornerstone piece of your process makes you go faster, then you might be doing something irresponsible, and it’s not sustainable.
Move Fast…in the Right Direction
It’s easy to misinterpret the speed issue, and many teams and businesses certainly do. In today’s world, we can get software built really fast, and it’s getting cheaper to do so. This does not automatically make things better for us. Speed without learning is truly wasted, as all you’re doing is building the wrong stuff faster. Make assumptions, perform experiments, get in front of real people early and often, and learn! Ultimately, it’s your knowledge that will make you successful.
Don’t focus on speed without knowing where you’re trying to go. Having a bunch of unvalidated features is still a waste of time, no matter how long it took to build them.
I’d love to hear your thoughts on this topic, or any topic regarding product development or product management. Stay tuned to our publication for more information regarding our second product, we’ll be launching soon! If you’re a product manager (or someone interested in product management) and would like to contribute to our development, we’d love to chat! Send us a note at hello@betterproduct.co
