A big part of putting together a new project is doing small, quick tests (e.g. iterations) around concepts that help you better grasp the overarching concepts and themes.
Said another way, building small, working prototypes can help you see more clearly the problem that you’re attacking and the possible solutions that could / might be deployed. And, if I’m to be honest, in many (most) cases it brings up more questions than answers.
But that’s kind of the point of the exercise, especially at the very early and concept stage: You have a hypothesis about X and you work quickly and efficiently to either prove it or disprove it and then rinse and repeat.
This is, of course, easier when you are smaller because speed is one of your greatest assets. The amount of agility that you have by yourself or with a small, tactical team, makes you an incredible threat to the establishment and existing products in the market.
A recent gif that’s been passed around is funny and yet all-too true:
Now, there’s no right or wrong way to build a prototype and there’s no right or wrong way to test them either. But I think there are a few important “guidelines” or considerations that I’ve come up with after having built a bunch of these over the years:
1. Build Small
This seems obvious but sometimes isn’t, especially when rubber starts meeting the road. It takes an incredible amount of discipline and practice to build small and stay small with the tests and experimental prototypes.
In other words, it’s way too easy to start adding bloat to your experiment and bolting on features or additional elements that you feel might make the experiment more “robust” or that might create higher signal around your hypothesis.
This is especially difficult in today’s technological economy where there are a million prototyping tools and toolkits and stacks that you can pull off the shelf that have 1,000+ features built right in that you probably don’t need.
Sticking to your core test (not tests) and not veering is really, really hard. An example that I’m working through right now is testing out a prototype news feed for our much larger application.
So here’s the challenge: There are only a few elements that I really care about in terms of the feed itself but since there are a million examples of well-worn and well-used feeds out there it’s really hard not to compare and contrast and start building out features that copy from those models.
My first-pass looked like this:
I had 14+ features that I wanted to build that “felt” right. The problem was that it wasn’t really solving my real test which had nothing to do with a gross amount of features! So I pared it down to 6 (5 and then adding 1):
I landed on these 6 for the base-level feed:
- Add text, post
- Like, unlike
The point is that even I, after having built a number of MVP products over the years still have a tendency to add unnecessarily to the feature list! It’s just too easy and too tempting.
Don’t get caught up!
2. Build Fast
The second suggestion and/or principle is to simply build fast. This naturally doesn’t mean that you should build it sloppily but remember, it’s just a test, a CRUD (Create, Read, Update, Destroy) prototype that you’re going to most likely throwaway anyway.
With that in mind, it is oftentimes better to not start from complete scratch especially since there are many existing frameworks and toolkits and APIs that you can lift off the shelf and deploy with speed.
So, again, I took a look around to see if there was anything that I could do to speed up my tests around feeds and I found a few good examples, data sets, designs, and even fully built-out services, like getstream.io.
I found some designs and made quick decisions on them based on my initial feature set above. Take a look at a few of the options:
For this small experiment I’ll move forward with “Option D” and experiment with the API and build a few custom things on top of it to get a taste. Obviously, using all of these artifacts and pieces of collateral speeds up my work significantly (and even makes it look pretty!) and if speed is truly one of my most valuable assets then I’m executing well against that principle.
I’ve worked on it for a week and I’m almost done and that’s pretty dang cool for something that’ll actually look (and feel) pretty “robust”. And, finding free services to do these light tests is always good and there’s no way that I’d even get close to the paid threshold for the service that I’m using today:
You see, I’m not even close to the 3,000,000 API calls offered for the free tier. Boom. Get it done!
3. Build Objectively
My last piece of advice is to build objectively and what I mean by that is to build something that you feel pretty emotionally detached from. It means that you’re building something that’s trying to prove or disprove a hypothesis and that most likely you’re going to end up trashing it completely or using bits and pieces of it as you move forward.
With this in mind, it’s good to remind yourself to stay fairly dispassionate about the implementation while not giving up the much larger vision and purpose of the not just the project but also this very specific exercise. It might feel single-serve and contrary to building something “scalable” but if the goal is to eek out new insight then the frame and shell itself is really quite secondary.
Contextually, the feed is just one part of the much larger vision of Building Better Software and one possible way of getting closer to doing that with our much larger data set. In many ways, this could be seen as just one feature of the much larger app, but it could be a critical one if we find our tests to be true.
I’ll share a bit more of the finished prototype when I’m done and I’ll provide a bit more insight into my goals, objectives, and some of the possible outcomes observed in a later post.
Build small, quickly, and objectively and you’ll do just fine.
Also published on Medium.