At Skillshare, we have a love-hate relationship with process. On one hand, it provides the structure and framework to turn great ideas into reality. Recurring meetings and the tools we use will make sure nothing falls through the cracks and that the ball is constantly moving forward.
On the other hand, too much process can constrain and limit a team’s creativity and productivity. If time is the most valuable asset to a startup, too many meetings and inefficient processes will slow your company down to a halt.
What we’ve come to realize is that in order to achieve the right amount structure for how your team runs and gets things done, you have to create scalable processes that adapt to the size, stage, and culture of your product team.
It’s also important to mention that the end goal isn’t about getting to the point where you’re shipping features as fast as possible and hitting deadlines you set for yourself, it’s about learning as much as possible to build a great product that satisfies the needs of your target market.
At Skillshare, this means creating a product that helps students learn collaboratively by working on real-world projects.
Behind every great product there’s an even better team. This means that every great product starts with building an all-star team. At Skillshare we are broken into two teams, the Community team and the Product team. Your Product team will typically consist of the following roles:
Product includes your Head of Product, Product Managers, and Product Marketing Managers. Depending on the size of your team, you may not need Product Managers or Product Marketing Managers. In the case where your founding CEO also functions as the Head of Product, like at Skillshare, you might need to pull in a Product Manager to manage the day to day responsibilities.
Your Head of Product’s main responsibility is to set the overall product strategy and vision. This means aligning the entire Product Team towards achieving the same goals. By setting goals, you help your team focus by deleting all the ideas that don't tie directly to one of your core goals. Every roadmap that we set and new feature starts with setting your goal and metric of success.
A Product Manager's responsibility is more about supporting the product team in every way possible. This usually means helping set overall requirements and specs for certain features, managing the overall process, and doing constant research, feedback, and support for your customer. Coordination between teams and making sure everybody knows the why of what they're working on is key.
Probably the most overlooked responsibility of someone who falls under the role of Product is achieving cohesion and consistency throughout the overall product experience. Too many startups end up over-featurizing their product resulting in a frankenstein user experience that isn't simple enough. At Skillshare, with every new feature that gets built, a feature needs to be removed.
Engineers are the builders of our product. They own the architecture and technical infrastructure of how our product gets built. Again, depending on the size of your team, you may or may not need a CTO, VP of Engineering, or any other hierarchical structure set in place. When working on a new feature or kicking off a new project, we make sure to bring in the engineers that will be working on the build from the very beginning to get their overall product input and technical feasibility of the build.
Designers drive the overall user experience, flow, interaction, and consistency with what you see on Skillshare. At Skillshare, we take a problem-driven approach to prioritizing our design elements. This manifests through deep understanding of our customer’s needs and problems to come up with creative solutions.
We believe in breaking everybody that works on product into smaller, more agile teams. This allows us to accomplish more faster by empowering each team with the freedom to experiment to reach the goals that they set for themselves.
An ideal team consists of cross-functional members that are able to take a feature from start to finish. This means at the very least having 1 designer who handles both the UX and UI and 2 engineers who build both the back-end and front-end of the feature.
A product manager would then help make sure each team is in sync with each other to create the cohesion needed in the product. This happens through a series of recurring meetings and tools we use to enable the process that we set in place.
Much like the early days at PayPal where David Sacks used to enforce an anti-meeting culture, we try to crack down on inefficient meetings as well. This means that meetings are limited to 30 minutes max and capped at 3-4 people. Each meeting will also have a lead who sends out prep work beforehand, sets the agenda of the meeting, and concrete action steps or decisions that need to be made by the end of the meeting.
Standing meetings work really well to this end, since your tired feet will be a good indication that the meeting is taking too long. We encourage anybody in a meeting who feels like they're not utilizing their time in the best way to speak up.
That said, impromptu collaboration and brainstorming sessions is what we seek as opposed to the traditional sense of a "meeting," since collaboration trumps the lone genius.
What we've found useful are a series of recurring meetings that happen on a daily or weekly basis that form our process for maintaining extreme transparency and over communication throughout the company.
Each day starts with a Daily Standup meeting that follows the same format every time. We go through each of our active projects that are tracked by Trello Kanban style. Recruiting updates and a quick 5 second roundtable of what each person is working on that day keeps everybody accountable and in sync.
Company-wide Town Hall
Every Thursday, we have a company-wide town hall to get everybody on the same page in terms of how we're performing based on the goals and metrics we set for ourselves. This is a time where we can all take a step back on the day-to-day execution of what we're working to view the company as a whole and understand what each team is working on and why.
Weekly Product Planning
The end of every week ends with a Product Planning session, in which we'll sit down and plan out the timeline of what we're working on for the next two weeks. We run based on a tweaked Scrum framework where we’ve taken the elements that work best for us to create two-week rolling sprints. Next week's timeline is always set with due dates and leads for each project, and the following week is loosely set with what's upcoming to have a good sense of what to prepare for.
As a caveat to this section, tools never work unless your team uses them. So, before trying to get everybody to use a new tool, make sure everybody understands the goals of the tools your team uses.
I won't go into too much detail about how we use each tool, but here's a list of what we use:
- Trello - for the overall product process
- Asana - for tracking individual action steps
- Internal Wiki - housing handbooks and documenting past projects
- Dropbox - syncing, backing up, and sharing files between team members
- Hipchat - internal company chat
To wrap up, before you tweak anything with your current process, make sure you have your culture principles set in place and a plan for building an all-star team.
Every team is different and requires a custom process to fit the needs of how you work. Take what works for you, and know that just like the product you’re working on building, you’ll need to constantly improve the process of how you run things allowing you to move faster and innovate.
If you like this post, upvote or leave me a comment on hacker news.