Category: development

The Product Solution Stack Test

(tldr; A product strategy is only as strong as its weakest link.)

The Twitter dust-up this week ostensibly about digital having been a mistake for newspapers felt a bit like Groundhog Day (the movie.) New day, same argument, same result.

Steve Buttry and Mathew Ingram both posted eloquent rebuttals:

Buttry:  The newspaper industry’s colossal mistake was a defensive digital strategy

The colossal mistake that the newspaper industry made was responding to digital challenges and opportunities with defensive measures intended to protect newspapers, and timid experiments with posting print-first content online, rather than truly exploring and pursuing digital possibilities.

Ingram: Sticking With Print Would Not Have Helped Newspapers Avoid Death

Shafer’s piece assumes there was some magical Eden in which newspapers were unassailable, and that it would have been possible to remain there if not for the sin of pushing too hard into digital. But that simply isn’t the case.

Newspapers were never likely to dominate digital in the way they had print. Many of the causes are secular – the Internet is a supremely disruptive force that inherently flattens structures, eliminates middlemen and creates value at scale.

Newspapers on the other hand were middlemen built to extract local value from news and advertising. The worth of local journalism aside, the future of the print delivery business was always going to be problematic.

But blaming our travails entirely on those outside forces risks ignoring the mistakes we do own. And at the product and development level, we failed at some basic digital blocking and tackling. Those failures can be attributed to a lack of systems thinking in our strategies, and a lack of respect for just how difficult the ‘system’ of a legacy media company can be to navigate.

Developers have a concept of the ‘tech stack’ to describe the collection of software and subsystems required for a project. A typical example is ‘LAMP’ representing Linux, Apache, MySQL and PHP in a common combination of operating system, web server, database and application/template software for a web site. Each component is dependent on the other and works together as a single system.

In product development, we also attempt to design coherent systems. But unlike a standard software stack, product solutions are emergent properties that reflect the desires, needs and constraints of a wide range of constituencies including humans, machines, cost and time.

  1. Reader Need (desirability)
  2. Business Need (viability)
  3. Visual Design (on brand and articulate)
  4. User Experience (function, usability)
  5. Development Effort (feasibility)
  6. Systems Integration (between disparate services and tools)
  7. Workflow (process for creating & publishing)
  8. Culture (shared assumptions that govern behavior)

Note that some of those layers (desirability, feasibility and viability) are typical human-centered design concepts. The others represent the people and processes necessary to actually bring a product to life including designers, developers and journalists.  To succeed, any product must ‘pass the test’ of at least minimally satisfying the requirements for each of the eight layers in that stack. And, because the stack crosses multiple organizational boundaries, creative and strategic conflicts will typically abound.

And more to the point, each layer in the stack is entirely capable of vetoing a product decision considered ‘solved’ in any or all of the layers above it. So, solving for seven is still a failing grade.

For instance, readers would undoubtedly prefer (level 1. Reader Need/desirability) a news site with no ads. But that would violate the need for revenues (level 2. Business Need/viability.)

And the further apart the levels the more complex the negotiations and solution will be.

Imagine a preferred design that dictated the use of triangular photos on the homepage. We could undoubtedly build the template and create a script to automatically crop images and avoid manual effort. But triangular photos are such a radical departure from accepted journalism norms the newsroom would likely reject the idea. (Possibly rightfully so.) So, all of the work to develop a product solution that worked from levels 3 to 7 would have been wasted, because we failed to solve for culture (level 8.)

So why have newspapers struggled with digital?

  1. Our guide star is often an internal business need, not an external customer need.
  2. We have failed to modernize many of our backend systems (starting with the CMS) causing many product strategies to fail at that level.
  3. In the name of expedience we launch features and products that do not meet the minimum requirements of all eight levels of the product stack.
  4. Our organizations are often siloed in a way that can return ‘false positives’ in the product stack test due to the inaccessibility of data.
  5. We have not explicitly enough discussed the complexity of the full product solution stack, so we have under-estimated the difficulty involved.
  6. We have failed to invest in the product and development resources that could help identify and resolve these issues.

When we solve those issues and are building products that ‘pass the test’ then we can go back to arguing about the ‘original sin‘ of digital journalism. Until then, we are still learning how to do digital media and are not ready to write the post mortem. Time is short, but the solutions are at hand if we take advantage.


Timing is everything

As the old joke goes, you have three options for any project: “Quick, Cheap or Good. Pick two.”

For better or worse, at least those are affirmative choices – assuming you make them well enough in advance of the deadline. But wait till you have a month or a week left and the equation changes. Now you can only pick one. And “Cheap or Good” have already left the building.

Is the tide turning for UX in media?

Here is a word that does not come up often enough in journalism-tech conferences:


Empathy for readers, for advertisers and for colleagues in other departments. (That last one is a big deal if you want to get innovative things done at work.)

Empathy is simply the ability to understand the feelings and perceptions of another person. And it is a key ingredient to making products a person (who is not you) might hope to use and enjoy.

Yesterday at Poynter’s Mobile News Summit (#mobilenews15) in NYC the concept came up quite a bit. Not everyone used the exact word, but their meaning was quite clear. The day was putatively about mobile, but it focused extensively on putting readers and their needs first.

One of my favorite quotes of the day was directly on that topic.

Question: Is there a business case for investing in user experience? Answer from Jim Brady of Billy Penn: Yes. Frustrating users is not a strategy.

Why personalization is hard (and why you need to aggregate.)



Since it launched, Zite has been one of my favorite apps. Keying off my Twitter stream the product does an absolutely amazing job of finding stories I am 1) interested in; 2) had not seen already; 3) from sources I was unlikely to stumble across.

That sort of personalization – saving time by accurately filtering information –  is of huge value to readers. If you can reduce the number of clicks (the currency of the web) needed to find stories of interest, I am likely to return. No surprise that most media organizations have recommended story lists on their websites.

But in many cases these lists are of minimal value. Browsing just now – five of the suggested stories were more than four months old. And I was reading about the Affordable Health Care Act.

The challenge is, even the most prolific news sites (say the NYT) only publish 1000 – 1500 stories daily. Even over a week or a month, there is not enough variety to make an effective recommendation in every case. So, older or less relevant stories are surfaced. But as a pure aggregator Zite is not restricted to a single news source. A billion new pages are added to the world wide web daily. That is more than enough to recommend 50 – 100 highly relevant stories to me each day.

Doing some news math, the filtering value (or number of potential clicks saved) to the user is not comparable:

Zite: (one billion possible stories / 100 filtered stories) = 10,000,000 clicks saved.
News site: (one thousand possible stories / 10 filtered stories) = 100 clicks saved.

Yes, that is a farcical equation and the news site still returns a positive value — but not enough to be competitive.

For news publishers, there are three ways to improve our odds: 1) Improve the algorithms to eliminate outdated or irrelevant articles; 2) Reach outside your own CMS and aggregate stores from other sources; 3) Start focusing your metrics less on raw page views, and more on efficiency and value created for the reader ‘clicks saved.’ (See Cory Bergman’s ‘time saved’ take on this earlier this year.)

Yes, those aggregated links will need to be highly relevant (see improve the algorithm above) and they will lead visitors away from your site. But, all Zite does is send me away. And yet I return every day.

Using Google Forms on a smartphone

I did a fair amount of Google-ing on this looking for a simple answer – without much luck.

So, in case this comes in handy here is a simple-ish way to use Google Spreadsheet forms on an iPhone for data entry in the field.

My current project is an ethnographic survey of news habits among commuters – with a focus on mobile devices. I have been gathering anecdotal info for a while on the commuter rail and T.

For class, I needed to formalize the data a bit, and wanted to use Google Spreadsheets. There may be better survey solutions out there that are mobile-friendly, but I have a lot of other stuff in Google Docs, so there you go.

Creating a form to gather Google Spreadsheet data is dead simple. And (previously unknown to me) you can break a survey form into multiple pages and contextually customize questions. That is GREAT for mobile use as it reduces the amount of content on a single page, and eliminates non-applicable queries on-the-fly.

Unfortunately Google Forms does not include any mobile-specific or responsive themes. It does work on a smartphone, but only with some significant pinch-zooming. This is especially a pain when using tiny radio buttons or check boxes.

The solution I arrived at is pretty simple, especially if you have access to a web server.

1. Set the theme for your form to “Plain” in Google Docs.

2. Limit your survey pages to one question each with 4 – 5 answers – eliminating the need to scroll to find the continue/submit button.

3. Use page breaks, and multiple choice options (which allow a redirect to specific pages based on prior answers) to customize the order and questions offered.

4. Embed the survey code from Google into a web page you control. Doing this on your own server is preferable as you want a completely blank page aside from the embed code.

Screengrab of a simple mobile survey page5. Drop a meta tag in the <head> to set a viewport. Something like: <meta name=”viewport” content=”width=320, initial-scale=.9″> I have not touched HTML much recently but viewport is not tough to understand and works on Android as well.

6. Set the iFrame width to 320 (or etc for your phone) and the trim the height to make it as short as possible, without losing the bottom of any page.

7. Test and adjust the viewport width or scale as appropriate.

8. Keep in mind this approach is not the most elegant use of a viewport, but my goal was iPhone specific so I was satisfied to hard-code these settings into the page.

9. Once you finish tweaking, you should end up with a decent looking mobile form, as pictured here, without the need to pinch-zoom every page constantly.

10. Suggest to Google that mobile-friendly themes would be great.