Product Management — replace yourself, move on. Three years at a startup.

I often read a lot about Product Management. Primarily my goal from reading blogs, news articles, and just general tweets around the idea of Product Managing is simply to gather ideas on how to improve my process — so I wanted to write about the process we’ve established at SyncOnSet.

I stepped into the Product Management job through a series of job switching, job replacements, and job creations. What I mean by that is I started out as an intern, the first hire on the non-dev side of things, and slowly replaced myself with more skilled people to take over the things I started. It was a great learning experience because it taught me a little about every part of the company, from sales to support, from biz-dev to engineering. Having the foresight to say, “hey, we should hire someone else to do this now in order to scale this properly” is not always easy. It requires someone to admit to themselves, “I am not the right person for this anymore, and I should bring in someone else to do this.” It doesn’t mean you aren’t good at what you are doing, it just means you are good at getting things going, getting things off the ground, but you know your limitations and you know what is going to help scale your company to the size it needs to be.

For myself, I’ve had 6 roles while at Wymsee — the parent company behind SyncOnSet. Intern, Customer Support, Sales Lead, Account Manager, Product Evangelist, and finally, Product Manager. I don’t think I would be able to do my job today without having dabbled in each of those positions. All of those roles still work closely with me in guiding my decision making for Product, both in terms of the tools we deliver, as well as the strategy behind how we go to market with our newer solutions.

Right now my Product Team consists of one Product Manager (myself), one QA, three Engineers, one Designer and one Customer Success Lead. How we work today is by no means how we worked two months ago, and I don’t imagine we will continue to work the way we do two more months from now. Our process is evolving for a couple reasons: our product is constantly growing, our team is constantly growing, our roles are evolving, and we also want to try new things. I wanted to write a little about how I think of things when it comes to the product management of SyncOnSet.

Here is how we think of Product:

1. Release More, Worry Less

Our process is pretty simple. We are customer-centric. In an attempt to capture 100% market share (make lofty goals!), we are focused on delivering a tool that our users not only want to use, but cannot wait to use everyday.

We (typically) release in small steps. Every now and then, we have a major release, but “major” is relative. What is major to us may be minor to you. A revamp of our sign up funnel (how users create projects SyncOnSet) to us is a major release. I categorize that type of release as major because it was greater than 3 sprints (in the Scrum method of agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration). That release cost us 4 sprints, which is 8 full weeks of dev work (but who’s counting) (me).

We can achieve a lot more in a number of small steps for a couple reasons:

  1. We get feedback more quickly
  2. The user sees incremental enhancements more frequently
  3. We don’t shock the UX
  4. Each release is more manageable: reduce scope → reduce stress → reduce errors

2. Own Your Part

The key to success is owning what you do. Once a sprint is defined, each member of my team takes control over their piece of the puzzle. They determine how they want to manage the day to day operations from sprint start to sprint end.

The entire Product process is a bunch of moving pieces that need to work hand in hand with one another to deliver a final… well… product. Once the product has been defined, I try to hand over the rest of the process to my QA Lead. She sits with the Engineering team and her great ideas help fuel development. She owns the QA process, making sure Engineering stays true to the Product spec I’ve defined. Our specs are a combination of mockups and google docs that define, in great detail, what we want to build and who we are building it for.

I’m around for one-off questions and to make sure that if we need to shift gears or spend some time on something else, we do it. Once a sprint has begun, I am primarily the point person in terms of deciding whether adjustments in scope are worth the time. I’m responsible for the release, so timing and deciding which corners to cut here and there are on me.

Intercom is a company I really respect in terms of accountability standards. I’ve taken their model and tweaked it a bit to fit our team’s personality, but here’s how we each own our part of the process (much of this was copied directly from Intercom’s website):

  • If the analysis of the problem to be solved is incorrect, it’s on the PM. Ensure appropriate research is done.
  • If the design doesn’t address the problem, it’s on the Designer. Ensure you understand the research and problem.
  • If engineering doesn’t deliver what was designed, or delivers it late, it’s on the Engineering Lead. Ensure you understand the problem being solved and designed. Plan appropriately and accurately before writing code and creating Trello cards (more on that later).
  • If it goes out with too many bugs and broken use cases it’s on the QA Lead. Test, test, test. Ensure the team tests realistic usage and edge cases.
  • If the team is spending too much time on fixing bugs and not adding new value per our roadmap, it’s on the Eng Lead. Ensure each project improves overall code quality.
  • If we don’t know how it performed, it’s on the PM. Ensure success criteria are defined and instrumented.
  • If it doesn’t solve the problem, it’s on the PM. Ensure there is a plan to improve product changes that don’t fully solve the problem.
  • If the user doesn’t know how to use the new feature, or cannot find documentation on how to leverage updates, its on the Customer Success Lead. Ensure there is supplementary material available prior to releasing, and be sure the material is clear and concise. I’d even suggest having this stuff done as early as possible so you can discover confusing aspects of your features early on.

3. Roadmap Everything, Always

Our roadmap changes every month, but is always set for the next 3–4 months. I try to make sure that I have specs ready for the next 1–2 sprints at any time, with extra mini-feature specs ready if things are scheduled to be finished sooner than expected. I keep those mini-feature specs in a hypothetical bucket to pull from. But the key is making sure that bucket of extra stuff is in line with tackling parts of your roadmap

  1. Sprints: defined for the next 2–4 weeks
  2. Goals: defined for the next 3–4 months — typically, with deadlines and contingencies
  3. Vision: defined for the next 4–6 months — very rough, typically loose ideas that align with Wymsee’s overall goals

I pull things into our roadmap from a few places:

1. Customer Feedback — the key to our success (with some filtration, of course). Typically we get this either from our sales team when they do demos or onboard new clients, when I visit clients myself for the sake of keeping up with the pulse of our user base, or when customers unsolicited, write in via Intercom or Both awesome programs that you should check out. I tend to really like the feedback from onboarding demonstrations. It really helps me understand what our customers expect us to solve versus what we actually deliver. This feedback is typically the information that helps us gain more of a market share because it comes from users who have never used us before. We can leverage that information either to direct product, or to direct our sales techniques.

Just because they request it, doesn’t mean they get it, but it does mean we need to consider the request and how much value it delivers against how much effort it is. We are a startup, so we need to stay agile and lean.

2. My Product Team — typically ideas from here help us make sure we are staying in line with trends. Users expect our software to do certain things, and those things come from experiences the user had elsewhere, in another app or service. So it is key we stay in tune with what’s going on. Currently we are exploring moving to AngularJS, and the decision is 3 fold: better UX, better code, more stability.

3. Company Mission — My product is one of many at Wymsee. I have to make sure the projects we work on fit into the overall company mission. Though every decision gets filtered through the idea of “mission” — even if they come through the other two points above — direct ideas from the overall company goals have their own path into my roadmap. All of our products work together, with mine at the top of the stream, so anything we do affects all other parts of the company.

4. The Tools Matter

We use a combination of Trello, Intercom, Slack, and now Mixpanel to help us manage Product.

  1. Trello: awesome tool that we use to manage product requests, bugs, and specs. Each card in Trello represents an idea, or set of ideas. Once we’re ready to pass that along to engineering, they make their own cards to put into their own process. Again, everyone owns their process, and decides the tools they want to use. Luckily enough, we use the same one :)
  2. Intercom: our lifeline to our customers. We use intercom to handle most of our customer support, message our customers for feedback, and guide customers through everyday tasks via event tracking — all in real time!
  3. Slack: our lifeline to ourselves. Nothing has to be said about this one, but typically, it’s where we can chat about something in a place where everyone can see things. We try to avoid 1–1 messages — if it is in a group chat, everyone knows how we came to a conclusion or decision on something.
  4. Mixpanel: tracks our users through predefined funnels. Right now we are in the process of releasing a new feature with Mixpanel built in. Hopefully, it helps us understand how and why people drop off as they are getting started with us. I’ll keep you updated!

Our process took around a year to get in place. Prior to my stepping into the Product Management role, we made decisions by committee and that was just a disaster. Defined roles, processes, and timelines ensures you are delivering products people want, when they need them. You find what works for your organization by trying things or by copying other company’s ideas and adjusting as you go. I’d suggest finding a company you like, trying their process, and adjusting it from there. Adjusting based on each member of your team’s suggestions is your best bet. The process is a team effort.

5. Involve Everyone (within reason)

Our release testing involves not only our product team, but also our sales team. The reason is simple: they need to sell whatever it is we’re working on. They need to be able to answer questions from our users while meeting with our customers. The only way to do that effectively is to know the product inside and out. So, they assist in release testing.

In order to reduce how much time they spend doing this, we only have them test features the end users will interact with, and we set a time limit on how long they can test. We typically cap it at 2–3 hours worth of testing per release. It’s generally enough time to get the sales team familiar with why certain product features are the way they are. Plus, since they work most closely with customers, they’re good at finding usability issues. Fresh eyes on a product can be very useful.

Demo everything. Show your team what you’ve been working on. As I said, we have a couple products, and we rarely cross-pollinate, so it’s not only helpful for the engineers to demo to their sales team, but it’s also useful to the other parts of the company that don’t work on our tool. We’re proud of our work, so we want people to see it. It lets people ask questions and better understand how all of our goals align.

This is just how we handle product at SyncOnSet. Every product is different, even within Wymsee, our own company, our products are run a little differently. Our tool powers the on set creative process for designers, crews, and studios. As the industry standard for filmmakers, thousands of productions around the world depend on our software each year, so we have to make sure our processes are sound so we can deliver value each and every day.

Check us out at or go directly to to see what we work on every day :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.