While listening to marketing podcasts, from time to time, I hear the term “social media expert.” I heard this term quite frequently back in 2008 when Twitter started to slowly increase in activity and users.

Fast-forward to 2013. I still hear some people use it, but I find it irrelevant for the following reasons:

1. Thousands, if not millions, of people use social media to communicate with others. It is now as commonplace as emailing someone or using a telephone. If I can send an email, would you call me an email expert? If I can successfully dial numbers on a telephone and speak to the intended recipient, can I add “telephone expert” to my resume?
2. Adding context to “social media expert” will make it meaningful. You could be a social media marketing expert, or a social media customer engagement expert, etc. Same thing with email: you could be an email marketing expert or an email direct-response copy expert.
3. Social media is becoming a wider spectrum every day with more social networks coming about, including Pinterest and Vine among others. Specializing in those social networks that make the most sense for you and your business or organization is becoming increasingly important.

What do you think about the term “social media expert?” Am I on the right track or off-base, and why?

As I’m writing this post, I realize that this is me thinking out loud. If you enjoy what you’ve read at the end, feel free to ask questions, make comments, and let me know if I have any gaps that need filling or if I’m completely off-base.

I’m an MBA in Marketing candidate. I’m finally done with all of my core finance, accounting, and economics courses. I’m now diving into nothing but marketing and international business.

I’m also a Certified ScrumMaster, Kanban board user, and overall big fan of the value that agile brings and the values that it espouses. Therefore, I’m trying to think about what I’m learning in the agile context, and I find that there are already some conflicts.

The big group project for this class is to create a marketing plan. In week 2, we are diving deeper into what comprises a marketing plan. The template that we’re using contains many sections such as company summary, marketing summary, SWOT analysis, product offering, marketing mix, and other items.

The attitude of this class seems to be to take a one-year, two-year, and five-year look at the company. My inner agile is screaming at me: how the heck do we know what’s going to happen in five years??? Is it worthwhile to prognosticate? Or is it better to set up a system that allows you to sustainably adjust to change?

I think there’s great value in doing the analyses that the marketing template asks of us if you are just starting out or if you really need to step back and take a hard look at everything. Let’s say I’m just starting out. Once I have all of these ideas on paper, my inner agile is telling me (not screaming at me this time): now you can learn, inspect, and adapt. If I keep going through the learn-inspect-adapt cycle, I’m pretty sure that I have a chance of being able to update the marketing plan regularly.

If I keep a good cadence and sustainable pace with updating the marketing plan, then the long, hard looks involved with the SWOT analysis among other things won’t need to be done annually or more frequently, right?

One other thing that I noticed: in the template, it said something along the lines of “look for trends; trends are long-term and fads are short-term.” Does that mean that you dismiss any pattern that you notice that hasn’t been happening for very long? Or should I merely dismiss things like the new Harlem Shake because I know in my gut that it is a fad? If you are doing frequent, incremental adjustments, then many patterns can become short-term. Are they really any less important or actually fads?

I love what the agile community as a whole has taught me and shown me. You’re making my homework more difficult than the university intended it to be. For that, I thank you.

Looking forward to your feedback.

I’ve noticed the use of canvases lately. I’ve taken quite a liking to Roman Pichler’s Product Canvas. I can also see the value of Ash Maurya’s Lean Canvas. Heck, they even have a website that lets you create canvases online.

So what’s with all the canvases to begin with?

I haven’t had the chance to use any of these in practice, but I can immediately see the value in them. As a fan of Kanban, I enjoy the ability to visualize my workflow, to be able to look at everything on a board and see how it all fits together. I suspect that the canvas method allows you to do the same thing.

The canvas can be especially useful if it’s a physical presence in the office and looked at by the team. The Product Canvas gives the whole product team the product vision, personas, and user stories for the upcoming sprint among other things. The Lean Canvas is an adaptation of the Business Model Canvas, and it divides the canvas elements between product and market, with the unique value proposition element straddling both sides.

Based on these examples, it seems like the best canvases are visual, customizable, and only include critical information. They are certainly better than a 200-page document trying to convey the same message that ultimately gets stowed away in a desk drawer.

Have you used a canvas before? How did it work for you?

It can be hard to tell the difference between agile and non-agile when managing projects. I have a visual way of accomplishing this. It is not exhaustive or the be all end all, but it is a good start.

Think of each piece of work that a person does on a project as a horizontal bar, which represents time working on it. The top horizontal bar is the work being done first, the next one down is the work being done second, etc.

Let’s look at a basic outline of a new website project. Here, we have a non-agile way of managing the project, with non-agile being traditionally called “waterfall”:

And here, we have an agile way of managing the project:

You can see an obvious difference with the way the bars are placed. Now, here’s what the difference means.

We can differentiate between waterfall and agile projects using vertical slices. In the waterfall picture, each place where the bars intersect is a hand-off point. Once the wireframing is done, it then gets handed off to the designer. Once the designing is done, it gets handed off to the developer for coding, etc. Here is an illustration of those hand-off points:

In the agile picture, the horizontal bars frequently run parallel to each other, and the starting and ending points never intersect with each other. This represents working collaboratively without a single person doing the “start -> finish -> hand-off” cycle.

Now, let’s see what happens when we take vertical slices of each set of horizontal bars. We’ll start with waterfall. How many sets of bars do you get with each slice?

Yes, one set of bars. You could get clever and have a vertical slice straddle a hand-off point and get two sets of bars. Still, your slice will have only two half bars instead of two whole bars.

Now, let’s look at the agile vertical slices:

At any given point, you can have one, two, three, or even four full bars in your slice.

The multiple full bars represent a cross-functional team (the functions being wireframing, designing, coding, and testing) working together collaboratively on the project. When they work together, they reduce the amount of errors and waste as well as the time it takes to finish the project. The result of this is:

• The website gets out to the market more quickly
• The market gives the team feedback on the website
• The feedback guides the team on the next iteration of the website, and then they again work collaboratively to get the next version quickly out to the market
• The feedback loop continues

I hope this gives clarity about the difference between agile and non-agile projects. This is not to say that waterfall is bad for everything and agile is good for everything. Just an illustration of how agile can be more beneficial for technology-related projects, include website and software development.

As always, questions and comments are welcome. I did the illustrations using Illustrator, and I certainly understand if you’re not clamoring for me to show off my work in an art gallery!

I have been using Personal Kanban for almost two years and have been experimenting with using a Kanban board for program management. I enjoy keeping things simple, so I use the this board as a way to take a quick look at the overall program status at a glance.

I’ll give you an example so perhaps you can visualize it and apply it to your own work:

I manage the administration of many scholarships and awards, which are divided into several different categories. Each category for the year has its own card. Each card moves through the different columns on the board, which are:

• Backlog
• Collecting applications
• Evaluating candidates
• Confirming selections
• Money disbursement
• Done

This doesn’t have to only be a non-profit program like what I’m working on. This can be several projects as part of a program or portfolio. In its simplest form, it won’t give you the expected ROI of each project, nor will it give you a detailed status report. It is simply an at-a-glance “what’s the overall status?” report. If you don’t have the resources, or even the need, to make it more complicated, then it should serve you well.

How do you think you can use a Kanban board for simple program management?

Tracking outcomes on your website is important because it tells you whether or not your website is functioning the way you wish it would. The typical web analytics program has thousands of available metrics, and you could easily drown in a sea of data if you don’t focus on what’s important.

Three examples of outcomes are:

• Someone made a donation to your nonprofit
• Someone downloaded your product
• Someone registered for your event

I have found the Acquisition-Behavior-Outcomes (ABO) Model, as championed by Avinash Kaushik, to be an extremely effective way of measuring outcomes. The model tells you three things:

• Acquisition - where did they come from?
• Behavior - how did they behave while on your website?
• Outcomes - what ultimately happened? Did they leave? Did they download your product? Did they donate?

Measuring acquisition can tell you if your website visitors came using links from other websites, promotions efforts such as email newsletters and social media postings, as well as search engines. Some acquisitions could be due to luck, but others could be due to your promotions.

Behavior can tell you certain things such as how many pages users viewed during a single website visit, how long they were on the website, or if they entered your website and then immediately left. Measuring the rate of the last item is more commonly called the “bounce rate.”

Outcomes lets you know if the users accomplished the goals of the website, such as making a donation or buying a product. Or perhaps they just left your website without accomplishing any goals.

If the behavior and outcome are what you wanted to happen, then great. If not, then you will need to analyze the website data and figure out how to fix what’s wrong.

If you use a website analytics program, what metrics do you use to measure site performance?

Hurricane Sandy was an absolutely crazy storm, and my thoughts are with those who lost loved ones, homes, and are otherwise still recovering from it. The storm hit my wife and I, but we were extremely lucky. No damage to the house or any other property, and we didn’t even lose power. It only gave us a scare. There are millions of people around us who weren’t so lucky.

If you wish to help with the relief effort, you can find out how to donate to the American Red Cross. If you have your own preferred organization that is involved with the relief effort, then by all means, donate to them.

Since I write this blog for you, I’d like to know if my topics are relevant and helpful to you as well as if I’m missing something. If you want to help make this blog better, you can take this short, four-question survey.

Your feedback is extremely important to me since I want to make this the best blog that I can for you. Thank you so much for being a reader. You can spend your time reading a million other blogs out there, and it’s humbling to know that you choose to spend part of that time with me.

Take the survey.

In the previous web development post, I talked about HTML, the basic building block of any webpage. CSS, which stands for Cascading Style Sheets, works directly in tandem with HTML.

Where HTML dictates what to put on the page (i.e. heading text, images, paragraphs, etc.), CSS dictates how it should look. It assigns HTML tags certain properties including height, width, color, font-size, font type, and many other properties.

So, let’s dive right in with some examples.

Let’s say you’re trying to figure out how to style your paragraph text. Here’s how you would write it in your style sheet:

p {font-size: 16px; font-family: Arial, Helvetica, sans-serif; color: #000; line-height: 1.5}

Here’s a breakdown of what we just did:

• We made the font-size 16 pixels.
• The font-family property is a special one; it doesn’t automatically assume that everyone’s computer will have the capability to read the font that you want it to. So, it will first try to load the paragraph text in Arial. If that doesn’t work, then it will try for Helvetica. If that doesn’t work, then it will simply default to the generic sans-serif font.
• We made the font color black. #000 is the hexadecimal value for black, which can be easily read by web browsers.
• We made the line-height 1.5, which simply means that the space between each line in the paragraph is half the size of the font itself. It’s 1.5 line-spacing instead of double-spacing, and it makes for easier readability.

You can take the line of code that we made for the paragraph tag and apply it to any other text tags, including the h1, h2, h3, etc. heading tags. Notice that when you write an HTML tag, it needs to be surrounded by <> but not in CSS. For example, you would write <p> in HTML, but we simply wrote p in the CSS code. Also, there are no closing tags in CSS like there are in HTML.

Now, CSS is not all about styling text. Let’s say you want to use it to style the header at the top of the page that contains the page title, navigation bar, your logo, etc. Let’s go ahead and style the header:

#header {width: 960px; height: 150px; background: #000}

We simply made the header 960 pixels wide and 150 pixels high and gave it a black background color. The “#header” element is simply a shorthand way of writing the HTML tag <div id=”header”>. A div tag represents a division of the page, a block where you can put images and text. You use the “id” to give it a label, which in this case is “header.”

These are the basics of CSS. There have been dramatic improvements in its capabilities, and it’s advanced enough that we can actually use it to put rounded corners in our headers and footers as well as execute gradient backgrounds. Both of these could only previously be done in Photoshop or other image editing software programs.

In a future Simplified Series: Web Development edition, I will post a tutorial that combines the introductions to HTML and CSS and will guide you step by step on how to make your own basic webpage.

Any questions, and is this helping? If not, then what can I do to improve?

I listened to a podcast episode of Global Product Management Talk called “Compelling User Stories.” It talked about the importance of user stories in product management and how they can be more effective than simply spitting out requirements: by defining the “why.”

I think it’s a universal trait in business to focus on the “what,” and I have done so in the past when it comes to processes. If more attention were paid to the “why,” then I suspect many people would re-think how they do their daily activities.

Focusing on the “what” when deciding product requirements and features looks something like “add a log-in screen to this website” or “add social sharing buttons to this blog.” Ok, great, but why?

In my Certified ScrumMaster course, we went over a basic user story template: “as a <user>, I want <feature> so that I can <do something with it>.” For example, adding the social sharing buttons could become this user story: “as a blog reader, I want social sharing buttons so that I can share my favorite articles with my friends who also have an interest in this subject.”

In just one sentence, you have entered the user’s mind and are designing a product feature for them, one that he/she will want to use.

User stories are also an excellent way for the business folks to collaborate more effectively with engineers and programmers. If both sets of people are working off of a complete picture, then the customer benefits.

Overall, great learning experience. I definitely recommend listening to Global Product Management Talk, following them on Twitter, and contributing to the conversation using the hashtag #prodmgmttalk.

Do you use user stories? How well do they work for you?