Emailing the org chart

Ever heard the term “shipping your org chart”? That’s when you design your product or organize your website based on internal power structures, not real customer experiences.

Sometimes these are huge disconnects in web design or product strategy. More often they’re just small details. Little things that don’t break the experience entirely, but they show a breakdown in the your ability to put the customer first.

In the last week, I’ve noticed two such cases where I could see the seams in a big company’s org chart.

Note to self

There’s a great little feature in the new Outlook iOS app when you send yourself an email (yes, I do this pretty regularly). The sender’s name shows up as “Note to Self”:

outlook appIt’s a nice little nugget that shows the Outlook app team did their research, saw a common action and then designed a feature to make it a nice experience. Now the reason I say “the Outlook app team” did this, is because here’s that exact same email in Outlook on my desktop:

outlook desktop 2

I’ve sent myself emails to track notes or to-do’s for years, and it’s never bothered me that it came from me. It makes perfect sense. The only reason I even cared is because I noticed the new experience and thought, “Wow, that’s nice. It *is* a note-to-self. Neat.” Then a little while later, I opened Outlook on my laptop and *whomp whomp*.

Does this ruin my experience of the app? No. Does it ruin my experience on the desktop? No. Does it remind me, blatantly, that there are different teams with different goals working on what is the same product for me outside of that company? You betcha.

Woohoo! Or not…

In case you think I’m just picking on Microsoft because everyone loves to pick on Microsoft, here’s an example from Google.

I’m a neurotic about unread emails. I hate seeing the counter and I hate being reminded that there are things that I haven’t dealt with yet. I wouldn’t say that I’m an Inbox Zero kind of person, because I’m perfectly happy to look at something and willingly avoid doing it. But I want to make that choice.

So when I finished opening, deleting or actively ignoring everything in Gmail this week, I got this message on desktop:

gmail desktop 2This time, I noticed because I thought, “Woohoo? That doesn’t really sound like Google. Must be left over from a long time ago.” There’s nothing wrong with it in particular, it’s just not the style that Google seems to take these days. And honestly, that’s only something a content strategist would notice or care about.

A little while later, I checked the Gmail app on my phone and:

gmail appWoohoo no more. Maybe a little dry, but that’s way more like the Google voice I’ve interacted with over the last few years. And since the Gmail app came a lot later than the web version, I’d bet that’s closer to what their internal guidelines call for.

Whether you prefer the woohoo or the straightforward tone, they’re definitely not consistent.

Again, does this difference break the experience? No. But does it tell me that there’s a disconnect in how these two (or likely more) teams are dealing with content and design inside their experiences? Absolutely.

So what?

These are pretty minor issues–even for something as mundane as email. But I’m pointing them out because they’re signs of something we all struggle with. More than the slightly disjointed customer experience, these differences are signals of inefficiencies and duplicate efforts for the teams that built them.

Don’t worry. I’m not just going to flame these teams and go back to my own org chart. Here are a few ways I’d recommend not making the same mistakes they did.

1. Talk to each other

This is the easiest thing you can do but also the easiest to stop doing when things get busy. To keep that from happening, schedule regular 1-on-1’s with partners to talk about what you’re working on and how they might relate or compete.

If you have separate teams for web and mobile or different teams for different parts of your product, use recurring team check-ins to make sure everyone is connected with their counterparts on the other side.

2. Review each other’s work

When we get heads-down on a project, we stop looking at what others around us are doing. Develop a regular process to make sure you can see each other’s work and give feedback. Invite people from other teams to your design critiques or demos to look for inconsistencies in the experiences or opportunities to connect with their work.

Sometimes it’s hard to make significant changes when you’re in the middle of a sprint or development cycle, so make sure you circle back with your partner teams during the planning and review stages. Don’t just create roadmaps for your own team, share them with other teams and look for potential conflicts or opportunities to join forces. After you ship, review the results as a group along with your individual managers or area leads.

3. Don’t sit in your org chart

You’re more likely to ship the org when you physically sit in it every day. Mix up where you sit so that you’re not surrounded only by the people who work on the exact same part of the product or are part of the same discipline as you. If you can’t move for good, at least go to other areas and work for a day or even a few hours. You’ll be surprised how quickly you start to think about the experience holistically when you’re not spending all day in your little part of it.

In Understanding Context, Andrew Hinton uses the example of a field with a stone wall to explain how physical boundaries affect our perception:

Such structures have a physical effect of stopping or slowing terrestrial motion, but they also carry a cultural meaning, such as “this land belongs to someone” or “keep your sheep on the other side, away from my sheep.” The wall changes the context of the field, transforming an open, undifferentiated vista into a specific human place with additional layers of significance.

The way we organize ourselves physically inherently affects how we think about our work and our products. Find ways to break down those walls, or at least step around them occasionally.

4. Wear the customer’s shoes

This is another step that’s easy to ignore. Take the time to test out your products or websites as your customers. I don’t mean playing with your prototypes, though. I mean actually going home, going to your website and trying to complete a common task from start to finish.

When I was at Facebook, every employee received a $250 credit to spend on ads, not as another perk, but so we could actually use the ads products as our customers do. We were encouraged to find a real business–friends, family members or local non-profits–and actually run real ads for them, then provide feedback on the interfaces and the results.

So go to your site. Sign up for a trial. Download the software. Check your email on your phone and your laptop. Take the tour. Read the app release notes. Whatever it is, make sure you’re stepping outside of your company and trying to see your work from the outside. You’ll be surprised how different things can look.

5. Think in experiences, not pieces

Does the customer’s experience start and stop within your area of responsibility? I’m guessing not. So don’t just think about the piece that you own–think about what the customer will be doing before they get to your part and what they want to do after. Do the experiences in each of these areas flow together, or can you see the seams? Look for ways to share designs, interaction patterns and content to support a more consistent experience across the parts, and you may even increase your team’s efficiency along the way.

During BuzzFeed’s recent reorg into separate news and entertainment divisions, CEO Jonah Peretti explained in a memo to employees:

Having a single “video department” in 2016 makes about as much sense as having a “mobile department”… Instead of organizing around a format or technology, we will organize our work to take full advantage of many formats and technologies.

Remember, you’re all in this together

When we’re heads down on a project, it’s hard to step back and take a look around. But it’s a necessary part of creating seamless experiences for our customers.

Customers don’t care how many product managers or scrum teams worked on an app. To them it’s all one company, and it should feel like one product.

Your customers may not explicitly notice when teams aren’t working together, but they feel the friction. And if it’s showing on the outside, you can bet people feel it inside the company.

Look for ways to connect the experience for your teams and your customers, or eventually the seams start to come apart for everyone.