[These are speaking notes from a SIPA conference in San Francisco. They’re a little cryptic. I’ve tried to expand a little for context, etc., but if you need clarification on something, please ask.]
When you talk about creative people and technical people, it’s not just marketing and IT, but fulfillment, accounting, business development, sales, production …
I’m going to address why these groups need to work together, how to do it, and what’s going to happen if the industry doesn’t learn this lesson.
Why creative and technical people have to work together
Very simply, there’s a right and a wrong way to do things.
There are good and bad offers, web design, seo, server management, programming, project management, content creation, and yes, marketing.
Anecdote: Story of bad emails I get all the time (can we “jump on a call” and waste my time) vs an email that addresses a problem I have and offers a solution (e.g., I noticed that you use WordPress and your site loads slow, I can help with that).
Forrester Research reported that fixing an IT issue post launch is 30 times more expensive that fixing it during the design phase. (Gerry McGovern article on LinkedIn)
In the modern working environment, jobs aren’t precisely divided up. Everyone is doing everything, but some people specialize. Which is why we have to work together across functional teams.
Some people are creative, some are technical, and some are both. These things can’t necessarily be trained. Sometimes it’s just the way people are.
Anecdote: IT: We don’t have renewals, but we do have automatic billing
Marketing: On a new 1-year order, set the bill to be issued after 9 months.
Anecdote: Sales guy: design us a prototype.
Tech: what technologies can we use?
Sales guy: it doesn’t matter, use what you want, we just want to see what you’re capable of.
“Technical” doesn’t just mean coding. Marketing has its technical requirements too, like reports. You need to establish tracking and reporting requirements early with the tech guys or they might have to rewrite their whole system later.
Tech doesn’t always mean computers. Your A-B test might be messed up by other technologies — different colors on different devices, printers, etc.
Anecdote: Story about stock codes and mailing house desire to be flexible with inside or outside equipment. We lose the ability to track what went wrong.
The lesson is to bring in the people who know the details, and do it early.
Understand the conflict between systems (templates) and infinite flexibility. Make sure you understand the programmers’ desire to systematize with templates and when that won’t work.
Example: Email signatures in Alerts (with Twitter or without). Product pages that assume every product will have a sample issue. You have to understand how templates work to avoid creating problems later.
Example 2: Content templates for online learning — make them specific enough that they become a form to fill out.
Bring in finance in up front as well to make sure your business model and payment plans will work.
Anything can be done, but there’s a cost.
Low tech workarounds can seem like a good idea but they eat up staff time, and accumulate. Once they accumulate you have a rube Goldberg mess.
A project might look simple to the editors and marketers and cause the IT folks fits, and vice versa. Get everybody involved and use spiral development to avoid this. Start with the big picture and work down into details.
But … explore several different options at the same time because some niggling little detail can totally derail your project — e.g., an email system that can’t attach PDFs or an e-commerce system that can’t do recurring payments.
How creative and technical people can work together
Learn what you can, but stick to your role. Don’t tell the technologist how to do things, and vice versa. Respect other people’s expertise.
Example: VP v my programmer re login information and security.
People do what they want to do. Get to know what assets you have, what they like to do, what they’re good at, and deploy those assets appropriately.
Get the operational people in the room when you discuss something. Supervisors and salesman often don’t know what can really be done and how things work.
For large projects
Get on a train …
One person has to take the point and do the initial research on the project. The idea is to understand the breadth of the issue and all the systems and departments that may be affected.
For meetings, let people know what you’re going to discuss ahead of time and let them sleep on it. Require them to interact with the agenda before the meeting. Nobody should come to the meeting expecting to wing it.
Anecdote: Yes vs. No programmers. The cigarette break.
Make sure the people actually doing the work are the ones creating the estimates.
Bring the technical people in early so the whole team spirals their way from the overall concept to the specific requirements.
Back and forth is inevitable, embrace it. Don’t think you’re going to write a perfect, static requirements document.
Requirements change – during development and afterwards.
Example: Programmer’s issues with ad sales and changing requirements. If you don’t build in flexibility up front you’ll be redesigning a lot.
For requirements docs, it’s very different whether working with inside people (involve them early and let requirements develop) or contractors for a specific task or new vendors. Also big vs. small projects.
Write complete sentences in your requirements document in addition to bullet points to make sure you get your point across. Choppy, abbreviated language can lead to misunderstandings.
Agree on testing upfront. Who does it, when, and how it affects the schedule.
In a big project, establish small goals and deliverables. Don’t let a developer go on for a month without some review / status update / demonstration.
Sometimes it’s best to bypass your own tech people.
Example: WordPress for Kiplinger Alerts.
Just because it can be done technically doesn’t mean it should be done in your organization.
If your tech team has sales people, make sure their incentives aren’t getting in your way.
Example Preferring ad sales over collecting an email address.
Good enough really is good enough.
Perfect is the enemy of done, but you don’t want to send out crap.
The bottom line is to try to understand and respect one another, and never trust somebody who isn’t actually doing the work.
The Looming Threat that will leave us all flipping burgers
The old strategy that most of us grew up on was acquiring the customer and monetizing that relationship. Cf. book of models
Under most of those models “reach” has value. You want to get the word out broadly.
But we know that’s not exactly true. Reach is only cost-effective when you have well-qualified people. But if reach is free to you ….
This is how Facebook is tricking publishers. They promise us reach so they can get data. It’s a bad bargain.
1. It devalues our content and perpetuates the idea that content should be free.
2. We put our content in the same context as cat videos and hashtag activism.
3. They’re using us to build their business.
Reach is only valuable if you’re still acquiring the customer. But if customers think they can get everything they need in their Facebook feed, they won’t have any reason to come to us.
Apple tried this with the newsstand and the iPad. Foolish publishers fell for it, but fortunately (and predictably IMO) that failed.
Facebook is doing it right. They’re going after data and aren’t forcing anybody to use certain hardware.
Don’t fall for the trick.
Computers seem to promise centralization — we’re bringing everybody together in one place, so they don’t have to use multiple devices, diff. accounts, etc. But the reality is often the opposite. Platforms are not interested in helping you have all the data you want. The platform’s first concern isn’t helping the customer, but acquiring the customer.
The high-minded promise of the platform is that people will have one place to go to get everything, but it’s not true.
Example: Magazine subscription
My two prescriptions.
1. Leave Facebook to cat videos. Starve it of serious content.
2. Get publishers to cooperate to create a true platform that addresses the needs of the publisher and the customer — not Zuckerberg.
3 main takeaways
- Respect other people’s expertise and allow them to have a voice at the table.
- Make procedures that require people to think about an issue before they discuss it.
- Consider the possibility that somebody else is eating your lunch because they’re working at tomorrow’s business model and you’re looking at yesterday’s business model.
If you’re not familiar with SIPA, you should be. If you’re interested in practical advice on how to prosper in your publishing business, meet me at their next major event: BIMS 2016. I promise you’ll learn at least one thing that will make the trip worthwhile.