How we’re approaching Product Design in 2017
Let’s keep making awesome stuff, shall we?
In addition to the work we do for clients, we’re pretty into making our own products. We love the process of finding an exciting idea and figuring out the best way to build something useful around it.
Over the last few years we’ve had our fair share of attempts at building our own products. Some of which have made us proud, and some -quite a few- had to go away to a farm with lots of other products to play with.
Each and every one of those projects has taught us something. Regardless of the results, we’ve grown through wins and losses and feel we’re more solid and knowledgeable as a whole after the experience.
Facing this new stage, we feel we need to take a look back at how we’ve been handling the creation of our own products and we thought we’d talk a little about them (well, some of them at least) to try and give some context as to why we’ve taken the decision of changing our approach.
So join us on this trip down memory lane, we promise you’ll have fun and learn some Aerohistory in the process.
We stumbled upon the possibility of making our own products by chance. We were working on Xapo’s website and we needed to find a way of changing a fixed header as the user scrolled down.
We were surprised to find that no one had put out an easy way of doing it yet, and we were even more surprised to find how simple(ish) it was to do. We did it, we used it for Xapo and we made it available to all the open-source community, so others wouldn’t have to go through the work we’d already done. And so, Midnight.js was born.
Instead of dumping a wall of code on Github and calling it a day, we decided to build a sleek landing page that really showcased the product and what it could achieve. The results were amazing. People from all over the world started using Midnight.js in the awesomest ways and we got some incredible feedback as a result.
A similar experience was how Read Remaining came up. We were working on a project for a client that involved navigating pages with excruciatingly long navigation bars. While doing research we found that sidebars did a poor job of showing users how much more they would have to scroll to reach the end of the page. Enter ReadRemaining.js. Now we can transparently show users exactly how long they have to read to reach the end of the page. Again, we chose to make it open-source so everybody could share in the Aeromagic.
On top of products that came up out of defined needs, we eventually realized that a lot of the tools and processes that were a daily part of our work could be really helpful to people outside of Aerolab, such was the case with Setup, a setup script that lets you set up your Mac just the way we like it with a ton of neat tools and plugins, or Booom, a nifty Dribbble extension that we felt essentially made life a little easier for designers with autoplaying GIFs and support for retina displays. This one proved so popular that Dribbble ended up adding most of Booom’s features into their product.
On the not-so-useful side of the scale, we built a decent amount of stuff that was just for fun and that was never meant to be particularly life-changing. Worth mentioning here are Pixel Counter, a desktop app built on Node.js that -surprise- counts the pixels on .psd files. Blockrain, an embeddable Tetris that -for some reason- seems to be extremely popular in Japan, a .psd template for the Nokia 1100 (This one was for April’s Fools) or the Aerostickers for Telegram and iMessage that we released last year.
We also made an effort to conceive products from a wider perspective. Startup Map was aimed at the local digital community, as a tool to compile information that up to that point was nowhere to be found. And Acá no hay luz came up in a time where Buenos Aires was suffering from unpredictable power outages, as a de-centralized database that would help citizens -and the local authorities- gain a clearer perspective of the situation. Acá no hay luz got featured on multiple media outlets, its effect was so massive that even the local government officially implemented a similar platform.
On a more complex scale, we’ve also created our own self-contained products. Basically, it comes down to apps, websites or products that sprouted from our process, from the current state of the industry or from things we observe on day to day life.
Such is the case of Grabbit, a logistics solution software that we came up with during a hackathon (The same one where we met the charming Eze Apelbaum). Or Jukebox, a service for crowdsourcing music on public places that we made to solve in-office bickering about who got to play music. The latest product to come out of our Lab came to existence after we realized we were having trouble conducting effective design meetings remotely, and so we built Shootroom, a collaborative platform that allows us to share, edit and comment on design pieces in real-time.
You could definitely say we’ve had our fun messing around with our own products, but the question remains. What’s next?
Our overall assessment of the process is that we love it and we want to keep betting on it. With that in mind, we realized that our approach to product design had been somewhat off the mark. The pitching process was messy, the allocation of hours and resources was uneven, own products conflicted with paid projects, the list of improvables goes on and on.
We want to keep making our own products and we want to do it right.
In order to do this, we locked the Partners in a conference room with coffee, magic markers and a blackboard, and refused to let them out until they found a way to make the process at least 70% more awesome. From this totally organic and absolutely non-coerced meeting, our lovely Partners came up with a set of guidelines defined to make sure the process is as neat and transparent as possible.
Aerolab’s awesome Product Guidelines of awesomeness ™
Objectives
Any and all products to come out of Aerolab’s Lab should have one (or many) of these objectives:
To improve an experience.
To solve a problem that’s common in the industry.
To explore new trends and technologies.
To complement in some way Aerolab’s daily life and/or business model.
To cash in big time and get us all houses in the Bahamas.*
*Not really. Revenue from Own Products is welcome, but profit should never be a factor when defining Products.
Rule of thumb
Our own products won’t focus on immediate commercial objectives. We should be extremely clear on how we are going to allocate resources to build them, so they get made without obstructing Aerolab’s other projects.
Time is money
We will allocate a set amount of 5.000 hours towards building own products each year.
One thing at a time
Products shouldn’t overlap. At the most, we will make two products each year, one each semester.
Timing is everything
The whole building process, from idea to launch, should take around three months. The three following months will be focused on Customer Acquisition and Business Development, as well as any required iteration to fine-tune the final product. A usual time table should look something like this:
Month 1: Prototype
Month 2: Iteration
Month 3: Launch
Months 4 through 6: CA + BD + Iteration
Maintenance
Once launched, each product will have a defined budget for maintenance.
Performance
Before development begins, each project should have clearly defined KPIs and evaluation stages. If its performance goals aren’t met, we’ll evaluate necessary changes, including the possibility of shutting the project down early.
After the initial six months we’ll take a look at the product and label it in one of two ways. A Win: Yay! The product is amazing, we’ll look for investors and see it through, or a Loss: Bummer. The product didn’t really take off and doesn’t seem like it will, so we’ll keep it on a maintenance plan, available to existing users and maybe even release it to the open-source community.
Team
Each product will have a defined team, just like any other client. There will be an ‘Owner’ that acts as a client. Teams will consist of:
Project Manager
Designers
Developers
Eventuals (Communication, Marketing, Branding, Illustration, etc.)
Note: once the Product is approved and the parameters are defined, it will be treated as any other paying client. Its resources cannot be re-allocated towards other projects. Having this as a rule helps us ensure that paying projects won’t interfere on own products, and vice-versa.
Methodology
Pitching
There will be an internal pitching and voting process, to define which ideas will be made into projects.
Customer Acquisition & Business Operation
At the moment we don’t intend to put our focus outside of Product Design. We’re not trying to become an Incubator or to break into new industries. For this reason, our plan is to conduct these aspects of the process through third parties, in exchange for equity.
If you’re reading this and you’d like to get involved on either of these aspects, let’s get some coffee.
Sharing the Knowledge
Projects should aim for transparency. Each launch will be announced and different stages will be explained through Aerolab’s channels. Regardless of the project’s outcome, we’ll share what we learned, how we failed and what we got out of each and every one of them.
On top of educational purposes, sharing this information allows us to gather all kinds of feedback from users, colleagues and whatnot. This way we end up gaining new insights and pieces of knowledge we never would have gotten otherwise. We love you guys, stay tuned. ❤
Edited by Guillermo Vidal Quinteiro.
Illustration by Ale Ramirez.
