At Skillshare, two of our biggest values are entrepreneurial drive and collaboration. We believe that a team of self-motivated, creative people working together will execute ideas that are 100x better than anything an individual ever can. This means there’s no single person dictating the features and projects we work on, and no matter what role or specialties someone has at Skillshare, he/she is first and foremost a creative problem solver.
Of course, when you have a group of independent, entrepreneurial people — each with his/her own ideas and strong opinions — the challenge becomes making sure that everyone is aligned and focused on solving the company’s biggest problems. This is where a very collaborative and transparent process comes into play. In this post, I’ll share some of our product team’s fundamental philosophies that empower autonomy while maintaining laser-like focus.
Solve problems, not features
To make sure our product team is always on the same page, every new feature begins with and revolves around a strategy doc consisting of 3 main sections:
Problem — What is the main problem we are trying to solve? Why are we working on this feature? These can be any problems (business, internal, user, community, etc) we believe are holding Skillshare back.
Hypotheses — What caused this problem, and what might solve it? A simple way we break this down further is by asking ourselves “Why does this problem exist?” 3 times, then “What has been working?”, and finally “What has not been working?”
Goals — How will we know if the solution was successful? What metrics should we measure to determine success or failure?
The key to this stage is to completely forget about all features and solutions and focus entirely on the problems that need to be solved. Only by establishing what we’re trying to accomplish can we begin to think about innovative solutions and experiments to test. It allows us to simplify what needs to be built and deploy MVP’s that optimize learning rather than launch overblown features.
Duke it out
The strategy step is so important for us that we never move into execution until we’re all aligned. This isn’t a “Kumbaya” formality where all ideas and opinions are automatically accepted to make everyone happy, though. Instead, we follow a rule of 3 — all problems, hypotheses, and goals must be prioritized and trimmed down to the 3 most important ones. We embrace debate and constructive criticism, and often force someone to play devil’s advocate when consensus is reached too quickly. Throughout this process, titles don’t matter; everyone has the opportunity to share their thoughts, and decisions are based solely on evidence and the merits of an idea.
It might sound extremely time consuming to require complete buy-in, but in reality, the up-front investment of making sure we all understand why we’re working on a feature allows us to avoid many of the problems that slow teams down. Everyone contributes their insights and ideas from the get-go, and we avoid getting into endless, subjective arguments about whether we “like” or “dislike” aspects of a feature. Instead, every proposed solution must tie back to the problems and goals we’ve established. With the strategy document in hand, we have a very structured framework that allows us to quickly and objectively evaluate possible solutions.
When a feature is ready for execution, we follow a typical 3-stage process: 1) UX, 2) UI, and 3) BE/FE.
Although the stages are very distinct, we have an explicit “no hand-offs” rule. Even when you finish the work in your stage, you do not simply pass it off to the next person. You stay involved the whole way through, still responsible for contributing and communicating with the rest of the team.
During UX, for example, Andrew – our UX designer – takes the lead with wireframing and crafting potential solutions, but the rest of the team will continuously give feedback through sketches and suggestions. We will also find ways to get external feedback from users. When the wireframes are finished, Jake – our UI designer – takes over primary responsibility, but again, everyone is still involved giving feedback.
Since a feature will inevitably change as details become more and more fleshed out, over-communicating ensures that everyone on the team understands why various decisions have been made. By the time the feature reaches BE & FE for implementation, there are no surprises, and we all buy into what we’re about to build.
We’re constantly working to further simplify and streamline these steps to minimize the amount of “process” involved. What we’ve realized, though, is that it is almost always better to err on the side of over-communication.