Posts Tagged ‘Product Development’

Interior, startup office loft. Friday Afternoon.

SUIT: Hey dude, you know Feature X that we were asking for?

DEVELOPER: Do I ever! I spent all week working on Feature X, and you know, I’ve really started to take a special pride in how it’s turning out!

SUIT: What if—now hear me out—what if we didn’t do that at all. Let’s just cut it completely. Instead, we’re going to do Feature Y: we’ll graph this one thing against this other thing, and have it automatically annotate and blah blah foo bar etc etc…

This type of exchange is familiar to most developers, and particularly to those of us working in the startup world. The “suit” might be an executive, a product manager, or even a designer (it’s just more fun to call the person who’s telling you what to do a “suit” in this context1).

There are a few different ways this conversation can continue:

1. The developer refuses. She’s worked too hard on Feature X, and dammit, you’ll have to pry it from her cold dead hands!!!

2. The developer begrudgingly agrees to throw out her precious work and start again from scratch, but she’s really not happy with it. Deflated, she might not work as hard this next go-round, and the suit might not be quite as inclined to reimagine the product next time (even if it seems like the right thing for the product).

At Chartbeat, we aim for the conversation to continue something like this:

DEVELOPER: Yeah, we can do that. Actually, you know when I said I’m taking a special pride in this thing? It’s because I anticipated that you’d want to do several revisions of Feature X, and I built some flexibility into the code, so making Feature Y will actually not be so hard. I’m almost glad you asked for this change, because now I have the opportunity to amaze you with how fast I’ll churn this thing out!

Admittedly, that’s a completely contrived example and an exaggerated response. In real life, we’d probably try to see one version through and actually test it out with users before deciding to go in another direction (unless we’re in the extremely early stages of a product/feature). Also, a little bit of disappointment in lost work might be expected and is totally okay—we’re not robots. And from a development perspective, it’s not always best to spend extra time making code super-extensible/flexible if there’s a high likelihood that it will never be used outside of its original context.

Continuous Iteration

But my main point still holds: to end up with the best product we’re capable of creating together, we need to be able to change directions, and we should expect to change directions several times.

We don’t have (or want) the luxury of moving from “requirements gathering” to “specification” and then to “design” and “development” phases. All of those tasks are happening in parallel, all the time. As our user researchers and product designers continue their own iterative processes, the “ideal product” will become clearer and clearer. When presented with a new or revised product goal, the engineering team needs to be ready and able to quickly move toward that evolved goal.

Getting Technical

Today I’d like to talk about one way we enable this kind of flexibility through our engineering practices and technology choices. I work primarily on the front-end (the code actually running in your browser: HTML/CSS/Javascript), so that’s what I’ll be talking about2.

A few months ago, we were starting to build out a couple new products, and as is always the case when starting a new project, we had to decide whether to keep using our old tools, or make some changes. In particular, we had recently hired a number of front-end engineers who weren’t too keen on our Google Closure-based JavaScript code.

Closure: The Good, The Bad, and The Java

Closure has a lot of cool features, but its best feature by far is its compiler. Briefly, a compiler is the software that takes the easy-to-read code that you write and turns it into the small/fast code that runs in production. Closure’s compiler is extremely good at taking a large codebase—for example, our multi-product internal library along with the large standard library included with Closure—and pruning it down to only the code that is actually used by a program, and then smushing that code into an extremely small file. This feature has proven to be a huge win for our “pinger” code (the code that runs on our clients’ websites) since that code is downloaded about 10,000 times each second, and appeared on 71 million unique pages in the month of November. Making that code small is a win for everybody on the Internet, and the Closure Compiler does a tremendous job.

However, to achieve these awesome compilation characteristics, Closure requires the programmer to add a lot of special annotations to the code that are not normal to JavaScript coders. In effect, to the developer it “feels like writing Java,” which as we all know, is a terrible feeling3. Closure also suffers from a small and generally pretty inactive community, which makes it harder to find helpful resources and generally just less fun to use.

In the end (and after much urging from our newer hires), we felt that these drawbacks were significant enough that we should explore other options in the JavaScript space.

Weighing Alternatives

Several developers decided to spend a Hack Week (an every-7th-week tradition at Chartbeat) independently trying out a few different JavaScript frameworks/libraries that we thought looked promising. At the end of the week, every person who had tried AngularJS4 seemed to think it had a lot going for it. In a meeting of our front-end developers that went on for way too long, we hashed out the pluses and minuses of making a switch to Angular.

Changing technologies would mean a new learning curve—a short-term drop in productivity—for all of our front-end developers, so it wasn’t a decision we took lightly. On the other hand, those who had tried Angular during Hack Week were excited by its possibilities—we felt it would enable the creation of better features, with nicer/better code, and would boost productivity once we got over the initial hump. At the end of the meeting, we had decided to use Angular for our new projects moving forward, and even to abandon a Closure-based alpha version of one of our new products and rewrite it using Angular.

We continue to use Closure to maintain our legacy codebases and for our pinger code (where the benefits of Closure’s advanced compilation/compression are really huge) but all new projects are now using Angular.

AngularJS: Making HTML into an Application Language

In my mind, the biggest benefit of using Angular is its usage paradigm, derived from its core philosophy that HTML is a document language and what we want it to be is an application language. In short, where most other frameworks have you write vanilla HTML and then, through some code process, grab pieces of the document and “attach” behaviors to transform the static HTML document into user interface components, Angular in essence allows you to extend HTML by creating your own HTML tags for your user interface widgets. The tagline on the Angular homepage sums this paradigm up nicely: “HTML enhanced for web apps!”

To illustrate the difference, under the more traditional paradigm, we would probably create our graph by having some placeholder for it in our HTML document, like:

Then, in our JavaScript code, we’d have to explicitly find that piece of the HTML document, and insert a graph drawing into it. Our graph might have labeled X and Y axes showing, 3 different lines of different colors tracking different properties over time, etc. All of the configuration for this graph would probably be embedded in the JavaScript code: everything from the very existence of this graph—we have to know to actually find it on the page and insert the drawing!—to how many lines, what data the lines should graph, which axes to draw and how to label them, etc. Any changes to the graph will likely involve finding and changing JavaScript code, and will almost certainly require a “programmer” type of person.

Not Your Grandfather’s HTML

Using Angular, we’d have an HTML document more like this (simplified a bit here):

If you’re thinking, “that’s not HTML anymore! What are these graph, line, and axis elements?”—well, that’s the point, Angular allows us to “extend HTML” to create those elements! In our JavaScript code, we would write code (called Angular “directives”) to implement the graph, axis, and line components. Those components would provide generic graphing capabilities, and they would receive their configuration from the attributes in the HTML document—for instance, the line with name="typical-week"  above would know that it needs to plot the data contained in model.series.typicalWeek , as configured by the line-data  attribute. Our JavaScript code doesn’t even really have to know that the visitor graph exists! We have turned HTML into an application language that’s allowing us to piece the view of our application together in a really nice way, by placing and configuring our user interface components directly in the HTML.

3 Graph Variations
3 different stream graphs using the same model data but different HTML templates. The model contains several data series, and each template displays a different stream graph by choosing a different set of series.

Now, I’m glossing over a number of technical details here, but hopefully this gets the general idea across. The flexibility gains over a traditional setup should be pretty clear: when a suit decides we should blow away a graph and create a different one with different info, it’s entirely possible that we only have to change the HTML to make it happen! The level of technical proficiency required to do this kind of change is now lower as well—it’s much more likely that a designer (or even a suit!) can actually make the change without a developer and prototype or explore new ideas. This kind of flexibility would be possible without Angular of course, but Angular especially encourages it by its very philosophy of “HTML enhanced for web apps!”

Closing Thoughts

This post has just scratched the surface of what our front-end engineering team is doing to increase and streamline our responsiveness to shifting goals throughout product development. One final note regarding this continuous iteration process: make sure you hire the right people. Our developers, designers, and managers have a mutual respect and trust in each other’s abilities. Without that trust, constantly shifting goals can very easily lead to frustration and disappointment.

More in-depth technical information will be appearing on our engineering blog more frequently, so make sure to check that out in the coming months if you’re interested in the details!

  1. As developers we just love to think of ourselves as rebels, although if I’m being honest about suits here, it was actually the development team at Chartbeat that had a tradition called “Menswear Mondays.” It involved blazers. Also, our CEO seems to only have one outfit, and it’s not a suit, but jeans, a white button-down, and cowboy boots. It must be a… British thing? []
  2. Our back-end engineers also have all sorts of cool stuff going on. For instance, Vadim embedded a Lua interpreter in our real-time database so that we can quickly prototype new APIs! []
  3. Especially when you don’t have Eclipse to make the experience flow nicely. Yes, I programmed Java for a while. Don’t flame me, bro. []
  4. For more on Angular, checkout the official site and this blog post from our own Harry Wolff. []
A quick recap of Part I of this post…
  • We knew Chartbeat Publishing was strained by UX debt
  • We were psyched to introduce some major new functionality into the product
  • We knew that we had to consolidate all our research and fill in knowledge gaps before the full design and dev process
  • We were working out of a glorified bomb shelter next to a demolition site, an atmosphere of adversity which likely hastened our eagerness to redesign

The research effort culminated in the construction of a massive affinity diagram or mental model, which neatly organized all of the chaos of a newsroom into a taxonomy of actions and behaviours. The top level of the mental model consisted of four main categories:

  1. Developing content – actions associated with actually creating content
  2. Assessing content – actions associated with measuring traffic to content
  3. Assessing audience – actions associated with measuring identity and quality of traffic
  4. Developing audience – actions associated with systematically building audience

Taking a look at the mental model, the “developing content” and “assessing content” categories were fairly concise. We had a pretty thorough understanding of the workflows, processes, and product opportunities. But for “assessing audience” and “developing audience,” things were a little murkier. There were a myriad of complex activities that seemed disorganized and in need of rationalization — we had unearthed all kinds of social media tricks and hacks, experiments in link partnerships, attempts to infiltrate Reddit, newsletter optimizations, Outbrain gambits, and a whole slew of other tactics.

And the survey data backed up our feeling that there were more people working on audience development and using Chartbeat than we had originally thought.

We reached two conclusions:

  1. We needed to sit down again with the publishers doing the most progressive work in the area of audience development and try to figure out what we’d missed, if anything, the first time.
  2. And, in parallel, we needed to prototype some ideas that came out of our own hypotheses about how to measure audience quality in a simple way.

Read the rest of this entry »

Last fall, the Chartbeat product team was hunkered down in an office space that could’ve made an excellent interrogation room. We temporarily obtained this 500 square-foot room to augment our main office, a sardine can of developers, designers, analysts, scientists, and a growing sales and marketing team.

It was… austere: four brick walls and a cement floor. There was a glass-topped table in the middle, a whiteboard, and a phone. Two windows separated us from the round-the-clock demolition going on in the adjacent lot, and you almost always had to shout to be heard. We even called it the murder room.

We were examining the roadmap for the Chartbeat Publishing dashboard. There was a lot on the table—all kinds of ideas for functionality that we wanted to add to a product that was starting to look like it had too much going on. There was no way we were fitting it all in to the current UI. The bulldozers were looking like a good idea. It was time to start from scratch.

But in reality, prep work for a top-to-bottom overhaul was already well underway. We had initiated a massive effort at capturing the state of the newsroom and the publishing industry, and were already thinking about how to align Chartbeat’s services with those conclusions.

Our Research Effort

Research is an ongoing practice at Chartbeat. We’re constantly talking to our clients, figuring out how they work and why they do what they do – even sketching out ideas together and evaluating concepts. Nevertheless, heading into the project, we wanted to consolidate of all our meeting notes and interviews, and confidently answer the following questions…

  • Who’s using our product?

  • What are their motivations, needs, and philosophies?

  • Where’s the industry going?

  • What will the newsroom look like in a year or two?

  • How will editorial roles evolve?

If we started by simply answering these questions, we knew good things would happen.

Gathering Information

To approach our research challenge systematically, we used ethnographic methodologies:

Interviews and Field Studies

If we weren’t on the phone firing away at our customers with non-leading questions, Mona Chaudhuri and I were hitting our clients’ offices on a semi-daily basis throughout most of 2012—picking brains, hearing war stories, watching them work, and bouncing ideas around.

Copious interview notes came from these many many meetings at places like The Blaze, NBC News, the Wall Street Journal, The New York Times, CNN Money, Fast Company, Slate, Financial Times, and dozens more. If you had an office in New York, one of us was knocking on your door. And if your offices were outside of New York, we were there too: Washington, London, Toronto, Berlin, San Francisco.

Diary Studies

We asked a diverse group of Chartbeat customers to keep journals of their day to day activities. The journals were written over the course of three weeks into Posterous (R.I.P) blogs. Some of the participants were given, i.e. gifted, iPads to more easily facilitate the entry of notes and ideas. Yes they were great as a lightweight field tool for entering notes, but more so the iPads were a great incentive to keep participants motivated.

We had some very prolific contributors… for example this guy: Jonathan Tesser at New York Magazine (at the time). Reading what his day was like in his own words was a fantastic window into newsroom issues. The ups and downs were so much more tangible—you could really feel the personal challenges in a way that other research methods just couldn’t uncover.


To get a quantitative perspective on newsroom ethnography, we conducted a survey, which asked people about their role, three day-to-day responsibilities, and the three long-term objectives that they are evaluated on.

Processing the Data

We dug into the survey data and immediately got to some interesting information. For example, 64% of respondents reported themselves as some type of “content creator.” And 36% identified their role as being at least partially on the business side. In our fieldwork, we were still talking primarily to editors and writers, so it was somewhat of a surprise to see that one in three people had some involvement in other aspects of the business, too.

We took the diaries and interview notes and boiled them down, then reduced them, and then reduced them some more into a mental model diagram (shout out to Indi Young and her fantastic book on the subject). The mental model represented everything we knew about newsroom behavior—it contained every discrete action or behavior taken by people in the front lines of a newsroom. There were a lot and they were extremely varied, for example:

  • “curate third-party content on Tumblr”

  • “harass writers to meet their deadlines”

  • “look for dead spots on the homepage”

above: a couple branches of the mental model


above: a grouping of activities within the branch: “Understanding referrer sources”

We consolidated the individual actions—several hundred—into larger groups. For example “curate third-party content on Tumblr” was put into a group called “build off-site brand presence.” And finally, all the groups were assembled into four high-level categories:

  1. Developing content

  2. Assessing content

  3. Assessing audience

  4. Developing audience

Everything that we observed and captured fit into one of those four categories. That gave us a way to maintain a broad perspective on the publishing business as a whole, with the means to narrow our focus down to specific workflows and actions through a highly organized affinity diagram.

At this point our ‘forensics’ work was done. Well, it’s never done, but we’d just completed a very thorough and immersive look at newsroom culture, workflow and the state of the publishing industry.

The output of this work – the mental model – gave us something to measure our product against as well. What actions were we supporting and not supporting? We brainstormed all the realistic and totally unrealistic things we could do to help our customers across the many facets of their work.

Tomorrow, in part two of this post we’ll focus on some specific findings of the research and how we used it to roadmap the next incarnation of Chartbeat Publishing.