DevOps Hits A “WTF?” Snag

Share

DevOps marketing It’s hard to get where you’re going if you don’t know where you’re going.

Consider DevOps, the merger of development and operations processes to speed applications to market. If the buyer and seller have different definitions of what it is, they’ll expect different results. Which is a recipe for wasted time and money, not to mention unhappy customers.

You Say “DevOps,” I Say…”?????”

For dreary confirmation of the confusion, look no further than a recent report from B2B ratings and review firm Clutch. Clutch surveyed 247 IT professionals about their use of, and views about, DevOps, starting with a question about what DevOps is. The four leading choices, with the percent choosing each:

  • 35%: “… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other [IT] professionals while automating the process of software delivery and infrastructure changes.” (from Wikipedia.)
  • 24%: “…an approach to operations … uniting development and operations teams to automate and standardize processes for infrastructure deployment…” (From Rackspace.)
  • 21%: “…a philosophy or ideology [with] many of the underlying principles and language … grounded in a combination of agile software development plus Kaizen, Lean Manufacturing, and Six Sigma methodologies.” (from Hewlett Packard Enterprise.)
  • 20% “…the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.” (From Amazon Web Services.)

What is This, Religion?

Culture? Philosophy? Ideology? This spread of answers, with no definition getting support from more than about a third of the respondents, shows an alarming fuzziness around what customers expect from DevOps, and thus how providers should sell it.

Before you all start shouting that you can’t “sell” DevOps like a network router or a software testing project, I get it. But there is “stuff” you definitely do sell around DevOps, whether it’s cloud infrastructure, code repositories, training or consulting.

So to sell those DevOps-related products and services, how about focusing on the consistent themes across the definitions of 1) collaboration, 2) communication 3) automation and 4) standardization, all of which deliver the holy grail of faster time to market for new software and services.

DevOps Positioning

In developing marketing content around DevOps products and services, then, avoid the religious wars around jargon and definition and focus on the key features and the benefits.  For example:

  • How our new chat software, code repository or staff training enable collaboration. 
  • How our workflow management, service monitoring or performance analytics software, or our best practices frameworks, improve communication.
  • How our scripting tools, automation server or support for Puppet and Chef enable automation and
  • How our development, orchestration or monitoring platforms increase standardization and thus improved reliability, performance and security.

And don’t forget, of course, examples from actual customers about how your products and services not boosted agility and sped new applications to market, but reduced costs or increased sales – the real bottom line.

If you’re looking for DevOps tools, by the way, check out this great list of 50 top DevOps tools, which does a great job of explaining the benefits of each. You’re also free to use, adapt or steal my sample drip campaign for DevOps products or services.

Do your customers, or clients, agree on what DevOps means and when they’ve achieved it? And does the confusion get in the way of effective marketing and customer success?

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Should We Really “Think Like Publishers?”

Share

Just when we all got used to the idea that “every vendor should be a publisher” comes word that, indeed, they shouldn’t. They instead need to be marketers who publish content to achieve specific business objectives.

It’s one of a number of good points in a very useful presentation “Yeah, it’s content, but is it marketing?”  from the PJA Advertising + Marketing agency.  It’s aimed at marketers who aren’t getting the return they need by content marketing efforts that cost too much or deliver too few leads.

Maintaining, promoting and monitoring an ongoing stream of great content takes too much effort not to tie it to concrete business goals, they point out. I like their advice to shift from a focus on “What (content) will we produce?” to “What are we trying to achieve?”

 Doing It Better

Among their specific tips:

  •  Tie branded content to business value by “understanding a conversation your buyer is interested in—and defining a valuable role for your brand to play in it. “ At each stage in the buying process, the role you play as content provider should change. (See next tip.)
  •  Make “the buyer journey your roadmap” In the awareness/education stage, teach them about why they might need a product or service. As they move into consideration, start talking about what features to look for in such offerings. As they move closer to product selection, start offering detailed implementation tips.
  • Think as hard about promoting content as creating the content. By simply using the scheduling feature in Hootsuite to schedule a series of promotional Tweets for each new post (instead of just at the original post) has boosted retweets of my posts, and my Twitter followers. Even simple steps to promote and target readers can pay off big.
  • Add a specific call to action to each piece of content, and track the uptake on them to measure the ROI of the hard work that went into it. Consider asking for something more specific than a generic “click here for more information” by asking for something that drives further engagement, such as subscribing to a newsletter, providing contact information, filling out a brief survey or registering for a Webinar.
  • Be flexible about formats. Coming from the long-form journalism world, it’s easy to think that every question needs a long, text answer. I’m finding that shorter Q&As, checklists, videos or podcast sometimes work better. An edgier format that’s more fun to produce is also likely to generate more interest.
  • Finally, and not surprisingly, the agency suggested to “grab a partner” that can handle some of the content marketing load better than you can. This isn’t as self-serving as it sounds. There’s a lot of moving parts involved in marketing automation and they’re changing quickly. By outsourcing what you don’t excel at, you can spend more time making sure you have a solid business goal for your content marketing.

Getting Started

Check out my sample content sequences for selling cloud services, security response and DevOps. And let me know what other IT products or services you’d like to see a sample sequence for.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Content Cookbook #3: Selling DevOps

Share

content marketing DevOps(One in an ongoing series of sample drip content marketing campaigns for IT vendors. Feel free to steal this sequence or, if you’d like help customizing one for your needs, email or call at 508 725-7258.)

DevOps is the process of combining historically separate development and operations functions to speed application deployment. This is especially useful for companies that need to rush consumer-facing mobile or social applications to market, or those that  need to roll out or test new features quickly.

But DevOps is a major change, especially for large organizations with complex and/or highly regulated software environments. That means opportunity for vendors that sell tools or services to help them make the shift.

Here’s a quick, and relatively easy, content marketing sequence to identify and rank prospects for your DevOps offerings.

Story One, for those at the “top of the funnel/awareness” stage: Explain DevOps and how it’s different and better than what came before. Describe how a DevOps org chart is different than a conventional environment where development and operations are separate. Explain, based on your actual experience with customers, to what extent DevOps is hype or real. Be realistic and honest about what types of organizations and business cases it is best suited for. Cite case studies and examples of how actual customers made the shift and the benefits they realized.

Offer this ungated (no registration required) to establish yourself as a trusted and knowledgeable advisor. Promote via your Web site, email newsletters, content syndication, social media, etc. The call to action is a link to a second, also ungated story, for prospects that are moving into the consideration phase.  

Story Two: Use the ever-popular checklist format for an “Is DevOps for me?” piece. Questions for readers to ask themselves might include:

  •  “Have I missed a market opportunity in the last year because I couldn’t field a new app quickly enough?”
  • “Is my A/B testing of new application features taking too long? How much would it be worth to speed that up?”
  •  “Do I have the stomach for the organizational and skill changes required to move to DevOps?”
  • “Do I have executive backing to make these changes and force my developers and operations folks to work more closely together?”

Promote this piece as you did story one, offering it ungated to attract the widest audience. The call to action can ask reader to register to read a third, gated piece that contains more detailed implementation guidelines.

Story three: A DevOps reality check for those in more serious consideration mode. Based on real-world experience, describe what it takes to implement DevOps in the real world. Make this a detailed implementation guide that doesn’t shy away from the tough changes in both process and technology needed to implement DevOps. Include sometimes-forgotten considerations such as security and how DevOps may affect databases. How much training, in what areas, and at what cost are required for your staff? Where do companies typically go wrong in their shift to DevOps and how can other companies avoid these mistakes?

Gate this with a short two to three field form (for example, name, email address, company name) that captures basic tracking information without scaring off too many readers.  (You can profile them more carefully later with additional questions.) Since every prospect’s needs are unique, the call to action can be to offer a detailed assessment of their specific DevOps readiness. For those who stopped at stories 2 or 3, continue to marinate them in other useful content until they’re ready for further engagement.

Note: In place of “story” in this sequence feel free to replace with “webinar,” “video”, “podcast,” “white paper,” or other format.) And if you have a product or service you’d like to see a sample sequence for, drop me a line or call at 508 725 7258.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Next: DevOps for Databases?

Share

Testing databases for DevOpsEarlier this year in a report for PricewaterhouseCoopers’ technologyforecast, I dove deep into the tools and processes required to merge development and operations and speed applications to market.

Yaniv Yehuda, the CTO and co-founder of DBmaestro, called to say we’d forgotten the vital other half of the DevOps story: The databases without which all those applications are pretty much useless. Without putting databases through the same rigorous version control process as the application code as they change, including compiling and debugging new scripts in the database, he claims, you’re pretty much asking for failures when the new code and databases hit production.

For example, if you want to add a customer’s Facebook likes or LinkedIn profile to their database record, you also have to add new code to your application to access that information and track their comments, likes and other actions. More than nine of ten changes in a database’s tables, he says, will influence how the application operates, and thus must be tested as part of the version control and release processes.

Comparing and testing database versions is more complicated than testing code, he says. “With code, you replace components from version `A’ with version `B.’ If you do that with a database, you lose its content, so you need to create a transitional code that tells the production database what to change to accommodate the new structures that were added in development- How to transform ‘A’ to ‘B’.” These new structures include schema, (table structure), database code (such as procedures and functions), and content used by the application (such as metadata, lookup content or parameters tables.)

Their DBmaestro TeamWork not only creates and helps debug the new scripts in the database, but also controls the change control process itself to ensure that important changes aren’t lost as distributed teams create branches, sub-branches or interim releases of new databases. For code changes this problem is solved through automated version control systems.

DBmaestro Teamwork links the development of the database code within the database to the management of the version control and deployment process itself. Even if the development process itself doesn’t change, he says, “You have to manage it, track it better, to know who did what when, and to prevent people from overriding each other.”

“This is an enforcer-type tool,” says Gary Leibowitz, the firm’s head of business development. “Anyone who tries to bypass the process is forced to run through it correctly. This allows the database, for the first time, to be an integral part of the change process.”

DBmaestro TeamWork is available now for Oracle and Microsoft SQL databases. Pricing is based on the number of active users.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Selling DevOps? Don’t Forget Security

Share

using security to sell DevOpsWhen we think about DevOps (you are thinking about DevOps, aren’t you?) we usually think about speed. By combining what used to be separate application development and operations into one continuous cycle, companies like Facebook and Netflix can instantly  tweak their Web-based offerings based on the latest usage feedback.

But in a “DevOps State of the Union” dinner hosted by a several cloud hosting and software companies the other night in Boston, security was a bigger topic than speed. One prong of the conversation was how DevOps could make it even harder to secure corporate data and applications. The second was how DevOps could instead be, in the words of Jerry Skurla, vice president of marketing of security management software vendor Firemon, the “last, best hope for security.”

Needed: Security Smarts

Either way, security makes for a relatively little-known area where you can prove your smarts as a provider of DevOps tools and services.

Let’s tackle the end-of-the-world scenario first.

Change, or so the conventional wisdom goes, is inherently bad for security. That’s because any time you tweak application code, update a driver or reconfigure a server or firewall you could create a security gap.  A recent HP report, for example, claims that nearly 80 percent of application vulnerabilities are caused not by poorly written code, but improper file settings, outdated software versions and misconfiguration.

Many DevOps devotees boast of rolling out not one new code package per week or month, but hundreds every day.  Consider that many of these updates might require links to new databases or legacy (read: outdated) corporate systems, or through the corporate network out to third-party data sources? It only makes sense that so much rapid, continuous change could create a security nightmare. And if you put every change through rigorous security checks, aren’t you slowing the rapid code releases that DevOps is all about?

The flip side of the coin is that real-time visibility into application performance will let developers find security vulnerabilities more quickly, while rapid code refreshes will let them fix those vulnerabilities more quickly. In this scenario a vulnerability found at 8 a.m. could be patched as part of a routine code refresh that contains other application tweaks before noon. In fact, says TK, DevOps could make it possible for smart companies to make strong security a competitive differentiator.

 

Insights Wanted

So will DevOps wind up being good or bad for security? Probably both, depending on how the industry tackles some pesky implementation details. For DevOps marketers, tackling these real-world questions provides great fodder for “thought leadership” blog posts, white papers, newsletters, and the like.

  • How do you enforce security-related coding and configuration standards without slowing code releases? (Skurla says this can be done by adding “built-in checks/processes” to emerging DevOps tools.)
  • How do you perform regression testing to ensure your latest release doesn’t open a security hole, again without slowing code updates?
  • How do you provide for code rollback so you can quickly withdraw a release that caused a security problem?
  • If you need an audit trail of who made what changes to which code and systems, how do you provide this in a DevOps environment without bogging everyone down in paperwork?
  • What balance do you strike between spreading the authority to quickly make needed code changes, and the need to control administrative access to your most critical systems?
  • How do you create a culture where your people speak up about a security problem in code they deployed, rather than staying quiet (and delaying a fix) in hopes someone else will catch the blame?

Where there are good, a new question like this, there’s opportunity to engage customers and set the terms of the marketing conversation. DevOps devotees, fire away!

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.
Share

when is a hard sales pitch too much?I’ve always felt that if you’re going to educate customers, educate them. If you’re going to sell them, sell them. 

Think of when you’ve been getting what seems like great, impartial advice from a realtor or a mechanic and they slip into selling you something. You know it instantly and you suddenly start doubting everything they’ve said. Not good for the old customer/vendor sales process.

I got to thinking about that when I picked up a cool marketing tool from DZone Inc. out of Cary, N.C., at the recent Red Hat Summit in Boston. The handout was a “Refcard” on “Preparing for Continuous Delivery.” One of more than 150 the company has developed, it looks like one of those glossy two-sided cards you see in bookstores that provide a quick “cheat sheet” on anything from Algebra to European history.

On the “Refcard“ for continuous delivery, the goals include “delivering software more quickly and frequently,” “increasing software quality” and “increased efficiency.” They described prerequisites including “development practices such as automated testing” and “tooling such as source code management.” So far, so good. The presentation looked, as Fox News like to say, “fair and balanced.”

Cheat sheets for algebra, European history and now, continuous development.

Cheat sheets for algebra, European history and now, continuous development.

Then I stumbled on a separate section titled “The Key Building Block of Continuous Delivery: Release Automation.” It said, in part, “the overriding aim should be to increasingly automate away more of the pathway between the developer and the live production environment. Here are some of the major areas you should focus your automation efforts on…”

Get Your Hand Out of my Pocket

That’s when I double-checked the sponsors of the reference card. One was PaaS (platform as a service) provider CloudBees. The other was application release automation vendor XebiaLabs. Bingo!

Yes, automation is important, but giving it such an outsize role in a description of “continuous delivery” tainted, for me, what is otherwise an excellent, in-depth summary of a complex subject. Other sections of the Refcard went into great detail on vendor-neutral topics such as “implementing a deployment pipeline” and how to “capture audit build information.” In such a context, the specific focus on automation stood out all the more.

It also stood out because education is something you do with relatively “top of the funnel” prospects. These are the folks who are just beginning to think about whether they need what you’re selling. They need to know what’s involved in using your product and how it works before getting a hard pitch.

Now a Word from Our Sponsors

In a white paper, of course, after the (relatively) impartial discussion of the subject, it’s perfectly fine to end with something like “We provide an automated intelligent deployment framework that reduces release costs and delays, and supports agile, DevOps and continuous delivery strategies.” But in a white paper, I try to keep this “word from our sponsor” it short, sweet, and contained in one section where it isn’t confused with the higher-minded education.

Now, if I were to include my own pitch here, it would say something like: “I provide clear, concise and powerful white papers, product briefs, case studies and other marketing content for prospects at any stage of the sales cycle. Drop me a line or call at 781 599-3262 if you’d like to learn more.”

So how did I do with my pitch? And do you think DZone went over the line with theirs?

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.
Share
Open source software marketing

Get the message? Open source is about control…

In my last post I described the threat open-source and internally-developed software poses to traditional, proprietary software vendors. This week, based on what customers tell me about open source, I’ll suggest some themes mainline vendors should hit in their messaging (and in their product development) to compete.

Open Source: Not Just for Free Anymore

First, some definitions, to clarify terms and emphasize the nature and scale of the change traditional vendors are facing.

Proprietary software is typically developed, owned, sold and maintained by a for-profit company. Think Microsoft Office, Oracle databases, or systems management software from HP, CA, or BMC. The customer buys a license and usually pays a yearly maintenance fee of 15-20% of the purchase price for enhancements, support, and upgrades. Also – and this is important – the vendor owns the underlying source code, and only it can make changes to it.

Open source software such as the Linux operating system, the Hadoop software library for “Big Data” analytics, and tens of thousands of other examples, is not “owned” by any one entity. It is offered free, or at minimal cost, by its developer. Just as importantly, its source code is available for modification by any user. The more useful and popular the software, the most users develop enhancements and bug fixes for it.

It is also sold and supported by vendors, some of whom also (or only) provide services. But the community drives its ongoing development.

...and Mirantis helps provide it.

…and Mirantis helps provide it.

This leads directly to some of the pressing pain points that are drawing the youngest and most innovative IT types to open source and away from proprietary software. Here are seven of these pain points more traditional software vendor need to hit in their messaging.

Hot Buttons

Speed: It’s long been an annoyance that corporate IT can’t meet user’s needs. With today’s shrinking product cycles and pace of change, the internal IT group – and often the company it serves – are toast if they can’t change adapt their services quickly to meet new market needs.

Messaging suggestion: Stress product features and case study examples of how your software speeds DevOps– style development, deployment, and enhancement of applications or services. Describe your ease of use, the number and range of supporting software libraries, and any “frameworks” or best practices you offer.

Cost: Maybe you can’t match the pricing of a start-up with offices in a third-tier office park (or no offices at all). But you should at least be in the same ballpark. If not, be prepared to explain why you’re worth more.

Messaging suggestions: Highlight flexible licensing terms, or your SaaS offerings that can help match open-source  cost and flexibility. If you can justify a higher price with your scalability, manageability, security, etc., explain it clearly. If you lack such advantages, go back to the development drawing board. If you require less in-house skills and tuning than open source alternatives, stress this as its a legitimate cost factor.

Collaboration: The day of the solitary coder sitting in their cube doing what they’re told may not be over, but it’s not where the market-changing innovation is coming from. One consultant told me of a very mundane trouble ticket application that turned into an enjoyable, “Is it already five o’clock?” project because he was paired with a business user in the development process.

Marketing messages: Stress any of the ways in which you support collaborative development, both within the organization and in the open source community. Have you open-sourced any or all of your components, or support open-source frameworks? Do you support or host some of your work in progress, in on-line repositories such as GitHub? Do you support, or encourage, the use of in-house collaborative techniques such as pair programming in which developers work as teams?

Excitement:  Your customers are struggling with small, exciting startups for talent. They can’t match the salaries at a Google or Amazon, or the potential stock payout at a startup. But they can get and keep good talent by giving them the chance to develop something important and game-changing.

Marketing messages: If your product was ever used to develop anything game-changing, highlight it as an example of how an internal team can accomplish great, and even fun, things. If you can include (good luck!) the name and photo of the developer(s) who did wonders at a customer, all the better. Make it personal and real. 

 Scale: Can your technology scale from zero users to thousands or millions in a week? If so, explain how; if not, maybe another opportunity to go back to the drawing board.

Marketing messages: What fundamentally new technology, processes or skills do you bring to the table that allows massive, very inexpensive, dynamic scaling up and down as needs change? What about your technology allows is to scale out to infinite amounts of data, transactions, users, data types or protocols?

Security: Most observers agree open source software can be as safe or safer than proprietary software. But that doesn’t guarantee that the right processes are in place to ensure the most critical vulnerabilities are found and corrected.

Marketing message: If your software or service has the chops to consistently outdo the open source development process in finding and remediating vulnerabilities, flaunt it. If you specifically play in the open-source security space, play that up, too.

Fun: Do you sound open-source, or old and tired?

Marketing message: Get a hipster to give your product an edgy name. Would BMC, Cisco, IBM, or EMC name a product  MongoDB, Cucumber-Chef or Voldemort?

Again, cost isn’t the main driver behind open source adoption — it’s top-line benefits such as speed, scalability and flexibility. Drop me a line if you need marketing collateral to help fight – or ride – the open source wave.

Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.

Using an E-Book To Make a Complex Sell

Share

Cover croppedE-books (short, illustration-rich explainers of complex concepts) can be good or they can be trite. Too much dense copy and they become as hard to read as the worst white paper. Too little copy, or a too-cute theme, and they turn off serious buyers.

Sonatype, in my opinion, hit the sweet spot with their promo pamphlet “Go fast. Be Secure.”  While I picked up a paper copy at the MIT Sloan CIO Summit last week, it’s crying out for re-purposing as an ebook.

It uses a medieval type face and “knights in shining armor” theme to explain how Sonatype’s  software automatically ensures that Java code from the global open source community (rather than from commercial software vendors) won’t pose a security threat to corporate developers.

Short and Sweet

They had me on the cover page with a concise value statement. “Go fast. Be Secure.” The subhead explains: “A true story of how Development and Security came together to fix the risk in open source.” Note the short, direct sentences. (One quibble: Using present tense would emphasize this is a service available now, not something that happened in the past.)

Keep reading and you see big, clear pictures and a maximum of about two dozen words per page, in large type for easy reading. The words are carefully chosen for maximum impact, without redundant background or jargon. “Development wanted to GO FAST. But Security wanted to slow down and BE SAFE.” I like that the wording is specific enough that CCF05252013_00002experts in software development “get it” but even an outsider (like a CFO or CEO) can get the general drift. And the illustrations reinforce, rather than confuse, the message.

About four pages in, the e-book introduces technical concepts and the pain point they solve. “Code became like Legos™ – applications easily assembled from thousands of freely available parts. Developers ran even FASTER and Security found it even harder to SECURE.”  Note there’s only one concept introduced per page, and not a word is wasted.

A few pages on they describe the answer: “Bringing SECURITY and SPEED together by building component intelligence and governance in from the START…using all the tools developers love to use today!” Again, the sentences are short, direct, and describe what’s new and better about their approach.

Halfway through the ebook they introduce their notion of “component lifecycle management.” This might turn a reader off as jargon if the vendor had led with it. Instead, they wait until they’ve described what type of components they’re talking about, what kind of lifecycle these components have and why those components need to be managed.

Ye Olde Mini Demo

The second half of the book is essentially a mini-demo of the service. There’s a standard format with a short, concise value proposition on the left (“AUTOMATE and enforce GOVERNANCE in the tools you use today”) and a screen shot CCF05252013_00001on the right. A one-sentence supplemental explainer sits under each screen shot.

One added benefit of the e-book format is that it makes these screen shots large enough to actually read — long a pet peeve of mine in conventional white papers and trade pubs.

Finally, at the end, there’s the call to action (a link to a free snapshot of the reader’s application vulnerabilities) and a “Learn more” page.

Looks Easy But It Ain’t

Creating an e-book this clear required, I would guess, a lot of gut-wrenching work behind the scenes. You need to:

  • Define very, very clearly the top two or three messages you need to convey.
  • Find a very, very clear and concise way to say them.
  • Choose your words carefully so you’re not speaking down to or confusing or reader.
  • Choose and execute a graphical theme that supports but doesn’t distract from your message.
Author: Bob Scheier
Visit Bob's Website - Email Bob
I'm a veteran IT trade press reporter and editor with a passion for clear writing that explains how technology can help businesses. To learn more about my content marketing services, email bob@scheierassociates.com or call me at 508 725-7258.
 Page 1 of 2  1  2 »