(gigaom.com) -- A friend who is a Google engineer once thought of a great idea for a browser extension. So he set to work and over the next few weeks he had built a prototype. It then occurred to him to check whether anyone had already made a similar product. Sure enough, a quick search turned up pages and pages of results for existing implementations of his concept ��? there was even a wiki to track the various incarnations!
It turns out this situation is common. Spend even a little time creating products and you quickly learn that every idea has been done before in some form or another. So to find success with your product, you need to rely on superior execution to make your product stand out and succeed. How do you execute on delivering the best engineering implementation? Here are a few tips for each phase of software development.
More from gigaom.com- Where Kim Dotcom and Mega have the edge on Dropbox and Box.net
- How to build better products
- How Sitegeist used great design to make census data cool
- Subscribe to gigaom.com
Many times when a product has an edge over competitors, it can be attributed to the use of a new technology that is only recently available, and that has not (yet) been utilized by others. For example, the increased computing power of smartphones enabled Instagram to perform sophisticated image processing that before may have required a desktop computer. In the case of my company, Minted, as browser rendering became more powerful, we were able to expand our in-browser editor to include curvilinear text, text that follows a path, and drag-and-drop edit boxes.
So it’s crucial to look for opportunities to leverage new developments in technology, which can often open doors to new features that distinguish your product from the competition. When you discover such technology, assess which resources will be taxed by using it, such as high memory usage, or broadband internet speeds, and confirm that this matches the resources of your demographic. For example, if you know that you’d like to use a technology that depends on HTML5, and you read a stat that HTML5 adoption has spread to 75 percent of North American users, going that route can unlock a novel feature that substantially improves your product.
When you are not yet sure of your feature set, and still at the stage where you’re playing with prototypes, there are two common pitfalls that can happen. Interestingly, they are the opposite of each other.
The first is that people sometimes make technical choices that are good for prototyping but will need to be rewritten down the line in order to scale the product. This is what led to a single .NET project within Google’s Linux infrastructure, which required custom attention until it was ported, and how new PHP-based projects still come into the world these days. The authors figure that if their project is successful to the point where it needs to be scaled, it’ll be a great problem to have â�?�?and they’ll deal with it then.
The trouble with that rationale is that it assumes in the future you and the rest of the engineering team will somehow have a lot more time and resources, and can comfortably rebuild the product with a more scalable architecture. But that’s usually not realistic â�?�? when your project takes off, you’ll have less time than ever. The reality is that it can take months or years to fully rebuild a product, and in that time your features inevitably stagnate and your userbase can defect to competitors out of impatience.
The second common pitfall is the opposite, where developers absorb the lesson of scalability so thoroughly that they become hung up on preparing for it. So from the beginning they devote precious time searching for and hiring a scalability expert. Or even though they have a perfectly good database in MySQL, they spend an inordinate amount of time researching Cassandra and Reddis just in case their pre-alpha product explodes in popularity. It can quickly turn into a form of procrastination that delays the product.
My recommendation for avoiding both mistakes is the same. Pick technical solutions from the beginning that are known to have scaled with other products in the past without causing enormous customization or pain. It doesn’t have to be the most optimally scalable solution â�?�? just one that is known to have worked well enough for others. Make sure there are large userbases running on the technologies that you’ve selected. And of course confirm it’s an actively supported technology with an ecosystem of developers, so that you’ll be able to hire people versed in it when the time comes. Once you’ve done these things, stop obsessing over other alternatives and turn your attention toward actually making a good product.
Once you’ve gone past the prototype phase and decided on your feature set, it’s time to polish the product. Remember the equation for determining how your end user will relate with your product:
User satisfaction = Rewards from using your product – Irritations
If you’ve addressed the first two points, you’ve already used advancing technology and prototyped an enjoyable product. But almost as important is the second part of the equation: reducing user irritations.
When users engage with a product, there are many opportunities for them to experience minor annoyances that collectively add up. For instance, maybe a button doesn’t give feedback and so the user is confused about whether he should press it again or wait. Or maybe a page takes longer than expected to load. If your users can’t find the right UI flow, they get annoyed and seemingly minor irritations add up, until the user crosses an emotional threshold and gives up on the product, or at least for that session. That’s never good.
The most polished experiences are usually achieved through a combination of:
- analyzing metrics and taking actions to improve them
- observing usability tests
- improving pain points of personally using the product
Let’s go through these one at a time:
Typical metrics include latency, error rate, and business goals, such as retention or conversion. For reducing latency on web pages, make sure you’ve run YSlow and followed Steve Souders’s best-practices for javascript, CSS, and HTML. Remember to keep yourself honest by continually checking real-world latency via profiling tools such as NewRelic, and automatically collate users’ crash and bug reports on your servers.
For UX flow, I’ve found the books “Don’t Make Me Think” and “Rocket Surgery Made Easy” to be helpful in describing the process for finding usability flaws.
Finally, the most polished user experiences often come from teams who avidly use the product themselves (or who have honest family and friends that do). When the engineers, product managers, QA, and user experience designers are confronted on a daily basis with the effects of friction in their product, it inevitably leads to the rough edges getting smoothed out, giving your product that extra edge that can make the difference.
Niniane Wang is the CTO of Minted. She previously managed engineering teams at Google and Microsoft. Read more of her writing at Niniane’s blog, or follow her on Twitter @niniane.
Photo courtesy of everything possible/Shutterstock.com.
Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.
- GigaOM Research highs and lows from CES 2013
- How HR can make the case for workforce analytics
- The 2013 task management tools market
No comments:
Post a Comment