RODALE: PREVENTION MAGAZINE

In 2008, Prevention Magazine was facing a problem. Although the intended audience of the magazine and website was 40+ women, in fact the average reader was 50+ and the average age was going up rapidly. Prevention clearly needed to engage new readers on new platforms so that it didn’t get permanently relegated to being “my mom’s magazine” or even worse “my grandmother’s magazine”. 

I convinced management to allow me to do three things: create an iPhone app, launch the brand on Twitter, and launch the brand on Facebook. The analogy I used was this: You can move somewhere, host a party at your house, and hope people (who don’t know you) show up OR you can go where people regularly hang out, make friends, and THEN invite them to a party at your house. Our intended readers were buying iPhones and starting to “hang out” on Facebook and Twitter so Prevention needed to be there too.

I quickly transformed our popular desktop flash application into a simple iPhone app. I also launched and then became the “voice” of Prevention on the two major social media platforms.  Within a month of launching, Facebook became our consistently top referrer of website traffic, usually followed by Twitter. Posts would regularly get comments far beyond the level of engagement we had ever seen in our Forums. We leveraged our social media audience to do sponsored live video streams that generated revenue.

Eventually, social media grew to the point where it justified hiring a dedicated staff person. 

Graphika had been existing for several years with a government-oriented business based on the founder’s algorithms and his particular skill in analyzing the resulting data visualizations. The company was hoping to expand into a more commercial market and needed to automate the data visualization product in order to scale the business. It planned to start hiring developers to work on the product, but management knew that just adding people is no guarantee of progress or speed.

I was brought in to establish a product roadmap and the Product Management structure and processes. It was soon clear that the initial core group of folks at Graphika worked well enough together to produce a basic product. However, even among them, there were gaps in communication and lots of assumptions being made. Newcomers didn’t understand what to do; they were not given adequate direction. 

There seemed to be a desire for organization; the Atlassian suite was being paid for but not used. So I started using it. I sensed that radical action would be counter-productive, so I began with small steps. I would speak to someone about a particular feature or function of the project, take notes, share the notes with the project group, and capture next steps per the discussion. In subsequent follow-ups, I’d refer back to the notes to clarify as necessary, capture additional decisions, establish the idea that all this information needn’t reside in one person’s head, and make it clear that we were building a knowledge repository. This iterative process slowly moved projects forward because there was an institutional memory and decisions were honored.

Eventually, as we hired more developers, I would clarify not only what needed to be done, but who was doing it. I would also try to elicit information regarding the key hand-offs so that they went smoothly and all parties got what they needed. Brief daily meetings (albeit initially, not quite a 15 minute scrum) and deep-dive planning meetings soon followed. Eventually, we were able to establish a sprint cadence and QA.

My work at Graphika was less about trying to establish a picture perfect scrum team immediately and more about trying to instill some structure around what had been a completely ad hoc and uncoordinated situation. Helping people realize that everyone’s work was intertwined and could benefit from sharing information and deliberate coordination was the key starting point for subsequent, more efficient growth, and higher productivity.

Tom’s Guide began as an offshoot of the more established brand, Tom’s Hardware, to help consumers buy all kinds of electronics (not simply computer equipment). Tom’s Guide was competing with sophisticated sites like CNet, The Verge, and The Wirecutter. Plus, visitors often confused Tom’s Hardware and Tom’s Guide. Tom’s Guide desperately needed its own new brand identity.

I led the rebranding effort. First, I led a small team of executives to select a design agency, orchestrating the choice of a smaller firm literally around the corner from our offices. My thinking was that the close proximity would encourage more face-to-face discussions, greater efficiency, and better results. We needed speed because we faced a very compressed time frame.

The team and I also really liked the agency’s adherence to Agile methodologies: working in small batches, making frequent deliveries, and checking each batch with a focus group. This meant we could keep up a steady cadence of work for our development group throughout this multi-month project. And we did bi-weekly presentations of each batch of wireframes and designs, akin to a Sprint Review, to a larger audience of key stakeholders to gather feedback as we went. This avoided most of the “Surprise!” at the end of so many large redesign efforts,and allowed us to make changes along the way. We got a great deal of buy-in early on.

Given the breakdown of traffic to our sites, we used “mobile first” principles in rebranding Tom’s Guide. It was very new for Purch to focus first on the essentials for the mobile experience instead of designing the mobile version as an afterthought, and represented the vanguard of the shift in the industry. 

This was one of the smoothest major redesigns undertaken by Purch, even while having its stress and compromises. In just over 6 months, we achieved our goal of introducing the new Tom’s Guide brand and differentiating the site from its “big brother.” 

During acquisitions much attention is paid to the balance sheets but much less so to the systems. When two publishing companies combine, the assumption seems to often be that since they both work with content - often similar content - it shouldn’t be THAT hard to migrate the acquired to the system of their new owners.  This blase attitude conveniently ignores the realities and the minutiae involved in everyday processes that keep the machine running.

When Penton acquired Aviation Week from McGraw-Hill, leadership believed it should be simple to integrate it into the Penton Content Management System. After all, my team had just finished two years of migrating 80+ brands from a variety of different CMSs onto a single common platform. What they did not realize was how different the two systems were. That became apparent when the transition did not move forward as expected.

I was the third person brought in to make the transition happen. We were working against a ticking clock since the contract with McGraw-Hill only allowed AW to stay on their systems for a set period of time; after that there was a monetary penalty. 

First of all, AW was integrated into the sophisticated workflow tool that all MH brands were expected to use. The Penton CMS had no formal workflow tools. No need for it had ever been identified. AW had been using this workflow tool for YEARS. It was embedded in their daily routine. Publishing a monthly magazine or publishing to the website was unimaginable to the staff without it. This was a huge issue that was completely missed/underestimated.

Second of all, AW.com was only the tip of the brand’s digital-offering-iceberg. Behind the paywall was not just more premium content, but rather lots of data and lots of data options and features and functions that were huge sources of revenue. Different pieces of it were maintained by different groups. And there were no clean, established user access tiers. Pretty much every customer had a bespoke package. Oh, and there was no documentation. And few people left who knew much about the entire thing.

The first thing that was clear was that the AW team was incredibly frustrated and their attempts to explain the complexity of the different parts of their product offering had either not been heard or not fully understood. Once I understood, I was appalled. The other thing that was clear was that much was not clear between the two teams, including the most basic communication. 

In the first tech team meeting that I attended, I noticed something and confirmed it...the two tech leads - one in NYC and the other up in Ithaca - were not understanding each other. They literally did not understand what the other was saying. Between accents and hearing issues and line quality, they had no idea what the other was saying and yet neither was saying so. Only after I asked each directly, did they admit they had no idea what had just been said and had just said, “OK” in order to move on.

Once I understood and acknowledged the complexity and the justified concerns of the AW team and identified the communication issues, it wasn’t exactly smooth sailing over the finish line, but it became much easier to break the project down into parts that we could then work through piece by piece as a team, making compromises and bridging gaps as necessary to make things work. Ultimately, we did complete the transition; and establish new processes to make sure that all of Aviation Week worked both for its staff and its customers.