A History of Product Development at betaworks
•
4 j'aime•1,815 vues
Slides from my talk covering a history of product development at betaworks in New York, where I work. I talk about bit.ly and chartbeat, and the paths and decisions made along the way.
![Inception ,[object Object],Iteration Rapid ideation and revisions to exploit edge cases, pivot Scale Scale up infrastructure, product and team to handle rapid growth](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (16)
Dernier
Dernier (20)
A History of Product Development at betaworks
- 1. a history of betaworks product development small bits, loosely joined
- 8. sketches
- 10. single page
- 13. bit.ly anywhere
- 14. Family history
- 15. bundle anywhere
- 16. curation
- 17. thank you
Notes de l'éditeur
- - I’m Neil Wehrle and I head up the User Experience team here at betaworks The term “Small bits, loosely joined” was coined by David Weinberger as a description of the Internet and here at betaworks often use it to describe the structure of our family of companies. - It also serves as an apt description of how ideas circulate and come together during product development here.
- - Our approach to product development includes three stages
- - The story of the Inception of chartbeat is particularly colorful. It has its earliest roots in a social website-sharing tool called Downfly, developed by a fellow named Billy Chasen, who has since gone on to start a company called StickyBits. Billy set aside DownFly and worked on Firefly and then chartbeat followed
- • Firefly was a real-time chat environment that site owners could include on their site. • Users could chat in real-time and “see” other users on the page. Here you can see how cursors would flit about the page, and users could just click to spawn a chat bubble and start chatting. Firefly didn’t work out well for a number of reasons, and a big problem was that sites had to have enough traffic in order to achieve a critical mass of simultaneous users. - but mostly users were completely weirded out by the experience of encountering random users on a website.
- And, the quality of the conversation left a lot to be desired. - What it did do is scratch some sort of itch regarding real-time data. - We learned that site publishers were really, really interested in a couple of features: real-time user counts and activities, and - the ability to go back in time, by means of a replay bar at the bottom of the page
- The next step was to re-orient these abilities into something clearly less consumer-facing, but no less interesting – a real-time dashboard of site activities. Initially, we thought this would be of use to bloggers and other content publishers paying close attention to Twitter. These were the only people we knew of who were interested in the viral loop and monitoring and responding to events as they happened. We priced it low, thinking people could afford $9.95 a month, and made it easy to install – just a line of code to call some javascript.
- Once we had a version up, we immediately began gathering feedback from users. We did using both methodical and more anecdotal approaches – we ran observational studies with actual users, conducted heuristic evaluations, and listened to our customers talk about the product on Twitter, the support forums and email communications. The initial response was very positive, but patterns emerged that shaped our thinking about the next version. Betaworks felt like it was really onto something now, so it brought in a new and larger team, and settled into a rapid, iterative design/build/test cycles.
- We spent a lot of time working together to nail down the first principles of the product and sketching out ideas. This creates a “shared space” for the team to externalize ideas and rally around. Typically, we’ll move from whiteboard, to my sketchbook, to a tool like omnigraffle (for a sketch, not specs), while building out technical prototypes.
- The idea of a shared space to externalize ideas extended to the physical space too Progress and responsibility is made transparent
- That we are designing for front users informed the first principle of keeping everything on one page. We talked to a lot of people who had access to “leading web analytic” tools, and universally they could not or did not want to use them. They can’t find information, and they don’t understand what they are looking at. Nobody but the most die-hard (some would say masochistic) data analyst wants to spend time drilling endlessly through navigational trees to arrive at a single pie chart of data. We worked extremely hard to move from a multi-page dashboard to a one that effectively communicates almost everything in a single view.
- The story of bit.ly’s Iteration phase is remarkable for its diversity and intensity. I would be remiss here not to use the term ”adjacent possible” as a description of how ideas collide, combine and build upon one another at betaworks. - Hitting its stride, an intense period of iteration ensued, which really hasn’t let up.
- The first year of bit.ly was largely dedicated to building out a robust API, supporting infrastructure, and partnerships with Twitter, TweetDeck and Twitterfeed. - The focus of the web site was mostly utilitarian – to get users their short link and to get them on their way. - When we showed users what they could do with bitly – namely click counts, and to a lesser extent, understand site content and how it traveled through the social web, they were intrigued and excited but didn’t quite know how to make use of it.
- - Bitly links travel all over the Internet, and we knew that people want what bitly can do – show traffic data, expose underlying URLs, etc. - in their browser. We spent a lot of time working on ways to extend bitly’s capabilities beyond the home page. We modeled and built browser extensions, iframes, and other approaches looking for ways for users to see that bitly links are more than just links
- - We reached back to some earlier ideas we had for bitly, including snapshotting page images, entity extraction on pages, etc. And borrowed from an element of findings – what we call the “sidebar”. - Basically a browser bookmarklet, the Findings version let people harvest, categorize and share content from the page they were on
- - Initially we thought users would be immediately interested in the social travels of their content, so we placed a heavy emphasis on sharing, clicks and referrer data. - With the addition of Bundles to the Sidebar, users can now harvest links they are interested in and build collections that expose relevant content to visitors.
- Bit.ly still has a clear utilitarian bent, but while the utility is more diversified, bitly stays close to what the core premise is all about. Click data, entity extraction, and sharing – all elements of earlier iterations – come together as part of the curation process.
- The set of ideas that drove the creation of chartbeat and bitly is much larger than what I’ve covered today These ideas continue to evolve and expand even as we learn from more mature products Thanks for your time and attention.