.png)
You might not realize you need Fences until you use it. It’s such a simple app that helps you organize your desktop icons into separate spaces—yes, fencing off different categories to organize your clutter.
Fences was developed by Jeff Bargmann, a life long app developer who needed a way to organize his desktop back in high school. The idea stuck, and years later became fully fledged Windows application distributed by Stardock. And so my messy desktop was changed forever. We spoke with Jeff to learn about its development, distribution, and the story behind the app.
Where did the idea for the app come from? Were you trying to solve a problem you’d experienced, or did the inspiration come from somewhere else?
Fences was a pretty fun story actually. While “Fences” didn’t come about until 2006, the original prototype dates back some six years to ~2000. I was in high school at the time managing our school’s web editors’ club, and noticed that the desktops across the lab were inconsistent, harming our team’s productivity. I had the idea to standardize the desktops with labeled groups for the projects we had the team working on. I was already deep into coding on Windows with other apps, so I decided to go for it, and “Desktop Icon Organizer” was born.
It wasn’t until another six years later that I decided to polish the edges and take the program commercial. I’d had my hands pretty full between college and other apps at the time. Until then I’d just been using the early rough version for myself, but enough people had noticed the app on my desktop and asked for a copy that completing the project became a pretty clear thing to do.
After you came up with the idea, what was the next step?
When I had the idea originally, the next step was to validate the idea technically. I began experimenting to see if it could be done, how it could be done, the best way to get it done, etc., and built a proof of concept. This technical deep-dive also critically helps you discover what’s possible, levels of difficulty and so on, so your “product team” knows their options while deciding what to make, and your “engineering team” knows how to cost and budget said options. This process has been the same for every product I’ve ever made.
Once I decided to commercialize the project, after completing the coding work required, the first step was to test it out in the market. I started up an invite-only beta, launch page and beta sign-up, and began talking with a publisher I’d had a long standing relationship with, Stardock. Together, we posted a link on a few message boards popular back in the day, WinCustomize, BetaNews, etc. to spread the word, and a few hundred people initially signed up. Testers could enter in why they wanted to be involved and how it’d affect their workflow, which helped us learn about customer motivations, and helped develop personal connections for great beta testing. Stardock, their CEO, and I worked closely together during this period but kept the app grass-roots until we reached agreement on publishing the app under their umbrella.
So the running themes above: next steps were to learn, validate and to simply keep moving.
What was your biggest roadblock and how did you overcome it?
Like with most apps, distribution was our biggest challenge with Fences. On top of the usual discovery issue, the feedback we kept getting was that people didn’t realize they needed it until they tried it, at which point they were hooked.
Fences did however have a distinct advantage in that it was highly viral by virtue of it’s visibility. People saw it on other people’s desktops, asked what it was, played with it then had to get it themselves. But the viral loop falls flat if you limit your adoption with a pay-wall or trial limitations.
So, we decided to take a pretty risky approach. Thanks to the app being published by Stardock, we had a fantastic platform for getting word out about the product. But instead of charging for the app, we decided to make it entirely free in hopes to find a way to monetize later.
This both worked and it didn’t. It did solve distribution. The first two years we got great traction. We were getting 35,000 downloads a week and had amassed over a million active users using and advocating the app. Trouble was that despite the time, cost and opportunity-cost of developing and marketing the product, no one was buying. The day—a year in—when we went freemium with “Pro” was a huge disappointment. And since we’d built goodwill based on the app being free, we couldn’t just start charging for it the way it was.
We spent the next year trying different approaches with Pro but it just didn’t take. The app began to languish. In fact, it sat for a year while we started working on other things, until we decided we had to do something. Had we solved our distribution problem and killed our product at the same time?
Summer 2012 we decided to make a brand new shining v2.0, and this one we’d charge for. We didn’t take away the free 1.0, but 2.0 had key new features users had been asking for like folder portals, some innovative new features like desktop “pages,” a brand new UI and some really great polish. Our hope was that if we provided a meaningful upgrade, we’d be rewarded for the work even if we charged. We tried it and it worked! Our 6,000 “download” hits per day instead became an established sales pipeline, and the incoming traffic didn’t go away like we feared it might. Users who didn’t want to pay could still find 1.0 free, so negative reaction was very limited. And to boot, we had a huge existing user base we could notify about the new version.
So in the end (and almost four years after) our distribution gamble worked out, but it wasn’t without it’s risks.
What was launch like for you? How was the reception of the app?
There were no app stores back in the day, so “launching” Fences was a much different kind of event. By the time Fences launched, thousands of people were already using it.
Instead of treating launch as the validation event, with Fences we let the product evolve naturally through it’s development, steadily reaching larger audiences, learning and adapting each step along the way. We tested with 10, 100, 200, 1000 people etc, and became more and more confident in our direction. A “launch” then just becomes a marketing event for a thoroughly validated product.
In contrast, having been part of iOS launches in recent years, I find this much more natural than the spike and inevitable “trough of sorrow” you see nowadays. On mobile, launches themselves become built-up validation steps that you could previously accomplish with much less drama; in fact many successful apps emulate these old days by launching soft. Unfortunately due to the transparency of today’s marketplaces, soft launching can give the appearance of floundering and staleness, and so isn’t always the right choice. Sometimes you still want to launch big, validate, pivot as needed and go from there. Thankfully, none of this was necessary with Fences, and the organic approach was the way to go.
How do you handle user requests and criticisms effectively?
Carefully. Early in my career I took user requests without much discipline, and learned the hard way that doing so leads to bloated and unfocused product.
Your job as a product manager is to extract themes and patterns from user feedback. With Fences, we collected this data on our message boards. In more recent apps like PhotoDrive, feedback links were prominent in-app to give users an easy outlet to speak up. Criticisms I treat like any countering viewpoint; in that it’s a data point, and data points form a trend. I carefully consider but don’t roll over, and encourage further counters to challenge my position. As I see a trend, I brainstorm with others and we come up with a plan to address. Pretty straightforward.
On the engineering side of things, criticisms must be jumped on more actively. I’m a big follower of the Toyota Production System methodology applied to software development. The moment you see a problem you drop everything and make a small allotment to remedy, to maximize quality and minimize build-up of technical debt. If unresolvable in that time, you make a decision on whether to prioritize or to queue. Fences is in a mature spot, but it’s a pretty complex product behind the scenes. Earlier on it was common for me diagnose issues via screen-sharing to see what was up. Now developing in iOS, I rely on exhaustively-thorough debug logs and MixPanel analytics to virtually “be there.” Reacting to criticisms on the engineering side is key to high quality.
What advice would you give to others that want to take on a similar project?
- Start small.
- Experiment.
- Experiment more!
- Just keep creating. Solve problems and be crafty.
- Learn. And validate. Step away, clear your mind and give it a hard look a week or month later. Do this more than once.
- Find partners! Don’t do this alone.
- Choose your partners very carefully.
- Develop a small group of trusted advisors.
- Develop relationships with mentors. Listen to them. Contribute in return.
- Don’t be afraid to fail. Try things. Fail fast. Learn. Keep moving.
- Not a lot of people get the chance to do something creative like this. Don’t forget to appreciate this and have fun.
Good luck out there!
Every other Wednesday, Behind the App gives an inside look at how some of our favorite apps came to be—from idea to launch (and beyond). Have someone you’d like to see featured? Email Andy.
from Lifehacker http://ift.tt/1IjHVkA
0 comments:
Post a Comment