1980k 1980k

Rise of the Product Managing Designer

The design team at Skillshare does a lot more than just design. We’ve learned that to be as effective as possible we need to break out of our traditional role and own much more of the overall product process.

Not to say that the world does not need product managers, but by equipping our design team with skills like a deep understanding of business, operations, and analytics we’ve been able to create more impactful products at a higher velocity. Below are a few core competencies of a product managing designer.

Understand your company’s business needs and goals.

Product managers tend to have a handle on the big picture. They understand the inner workings of the business, its goals, and the focus of each team.

Without this understanding, it is nearly impossible to judge a good product idea from a bad one. Even worse still, you will be rendered unable to anticipate the repercussions of your decisions unless you consider how it relates to the larger whole.

It is critical for Skillshare’s design team to have a comprehensive understanding of the ecosystem and how each project will affect it. We do this by syncing on strategy with everyone who might have a stake in the game early and often. This happens well in advance of the formal design process. By aligning with the relevant teams, we are quick to understand how our strategy will be helpful or hurtful to them. For example, syncing with the content team on the tools they use to create classes informs what strategies we ultimately push and enables us to move forward confidently.

The Skillshare design team has gotten very good at choosing what strategies to pursue, and perhaps even more importantly, what doesn’t look like it will work, before we ever start designing.

Design doesn’t matter if it never ships.

Product managers are judged on their ability to get things out the door. This means they’re relentless when it comes to minimizing scope and sticking to a schedule in order to maximize their impact. They’re also great at taking a complex strategy and breaking it down into manageable chunks.

Because our product managing designers are responsible for strategy as well as timeline, we rarely design features that would take more than a week to build. That’s not to say we don’t work on big projects. It simply means that we invest upfront in working through how we can break a project down and get smaller pieces out the door (prioritized by impact). We quickly and effectively ship the “must-haves,” but will often deprioritize the “nice-to-haves.” This is a fact of life for a small product team, but the benefits far outweigh the negatives: 1) smaller releases are easier to QA and support, 2) much easier to iterate and 3) reduces product debt with bloated features that no one uses.

This way of working provides a strong sense of accomplishment for the product team. It also helps boost momentum companywide, since progress builds energy and keeps people excited. At Skillshare, we send a companywide email every time something ships out to the site. We believe it’s important to celebrate the wins.

Own the metrics and feedback.

Product managers tend to be an analytical bunch. Once something hits the site, they immediately start assessing its impact to see if the new feature in which they have invested so many resources is working properly.

Product managing designers need to be the same way.

At Skillshare, this means setting the right goals (realistic and measurable) at the start of a project during the strategy and alignment phase. We then loop back around immediately once something has launched and measure its effectiveness. We also keep a close eye on all other feedback sources, such as engaging with angry (or happy) tweeters or gauging user reactions with the help of our support team. Taking initiative to actively monitor results and then being proactive about updates is the only way to make a smart path forward.

This may all sound obvious, but it’s easy to ship work and forget about it. If you don’t actively reflect on your successes and failures, you will never learn what works and what doesn’t.

To dive even deeper into how Skillshare builds product, you may be interested in: Optimize Your Team for Impact over Speed or Golden Rule of Managing Up.

Read More
1980k 1980k

How to Avoid a Common Product Mistake Many Teams Make

I’ve been involved with technology product design in one form or another for nearly 25 years and seen one mistake consistently repeated.

Design for the Novice Configure of the Pro

The single biggest mistake most product teams make is building technology for what they believe the user would want rather than what the actual end-user needs.

From the experience in my earliest days of designing products for Windows and OS2 machines in the early 1990′s I developed a product philosophy, “Design for the novice, configure for the pro.”

Most technologists design for themselves and then test with uncorrelated user groups only months after product launch – if ever. If you’ve never sat through real user testing where users are given simple tasks to complete with little to no instructions on how to complete said tasks you will be shocked when you see how what you assume are the simplest set of tasks create the most difficult user experiences.

I learned the hard way.

When computers moved from “green screens” to Windows we – the educated, young, technophiles – easily grasped the concept. It was hard to imagine customer service reps who had learned every keystroke short-cut by heart on a green screen and weren’t eager to embrace the obvious future. We worked evenings and weekends getting a system read for public utility employees to be able to move into the future and have more power on their desktops than the dumb terminals they were used to.

The earliest user testing proved disastrous. The CSRs wanted nothing to do with drag-and-drop, point-and-click mouse commands. Computers were a necessary evil to getting their jobs done and frankly what they valued more than anything was maximized their hands on the keyboard (versus lifting one to grab a mouse) and processing orders efficiently (versus having more options, more power, more choices).

We live in world of choice and yet paradoxically as humans we generally want fewer choices. We want less complexity.

Think about your experience at a restaurant with too many options. The owner thinks they are giving you the ability to have anything you want and you are thinking, “oy, vey, can’t you just give me a few well curated options?  The less you frequent the restaurant the more this is true. You’re not a master of what’s on the menu and you don’t want to invest the time to parse through all of its complexities. So you turn to the waiter and say, “What do you recommend?” or your order from the specials.

Yet the restaurant owners, chefs and waiters know every item on the menu by heart and wonder, “What’s the big deal? Just choose what you like!”

Perhaps this could be a metaphor to remind you that the kitchen always finds it easy to know what’s on the menu while the casual, infrequent designer could care less. They came in just to eat the best you have on offer from a limited menu so they can enjoy themselves, not stress out, and get back to their lives.

Bad design was further reinforced through a decade+ of building apps in a Windows era where we technologists were trained by the ever expanding menu options in every Microsoft product. We all created mini Cheesecake Factories.

Design for the Novice, Configure for the Pro

My philosophy is simply. You design your product for the non-technologist. The “Normal.”

Give people fewer options, fewer choices to make. Give them the bare essentials. Design products for your mom.

Know that when you look at the data you’ll find out the overwhelming majority of your users will come to your application infrequently and so you can’t assume they can easily orient themselves. If they can’t, they won’t return.

I know you want to build really powerful features into your product. You want to build in the capabilities that YOU would want. And frankly after launch you’ll get a laundry list of all the things your power-users tell you needs to be in your product to get the job done.

But here’s the thing.

Said power users will always find the features they need in your product even if they’re hidden away. Give them a configure button somewhere. From there give them options to soup up the product and add the complexity that goes with newfound power.

But make sure you keep it hidden. Make sure the novice can’t stumble across it and get confused.

And don’t take my word for it. Do actual usability testing and make sure to include users not from your ordinary circle of friends or similar cohort.

What you assumed was “novice functionality” will likely be too hard.

We built our product at Koral in 2005 with this design philosophy in mind. After we were acquired by Salesforce they asked us to do proper usability testing with well designed tasks to complete and we turned on a camera to record the sessions and review the basics.

  • Upload a file to our system
  • Create a new folder
  • Move your file to the new folder
  • Send your file to friends
  • etc.

It was simply mind boggling how what we assumed were intuitive, simple, no-brainer tasks were not well understood by basic users so unless we were only building our product for San Francisco-based techies we were going to struggle to scale.

I have worked with teams who fully embraced the user testing espoused in the Lean Startup movement and they often build much better products by watching feedback earlier in the design cycle.

So when you’re doing your next product review make sure to question all of your assumptions.

When you’re adding more menu options ask yourself whether you should leave stuff out.

Remember that often Less is More.

Don’t build for yourself or your friends who use your product and say, “wouldn’t it be nice if you could just …”

And certainly don’t build for your VC. They often have little or no design experience.

Sure, your friends and VCs are smart so I’m not saying don’t take input.

I’m simply saying …

Design for the novice.

And no matter how often I recommend this for teams with whom I work I still always hear the feedback, “Yeah, but, we just need to …” as an excuse to add more functionality back.

Hit the user testing. Find out for sure.

And in a mobile world I’m sure you know that this is even more important. People are opting for apps with less functionality and more easily adopted.

Source

Read More