PRODUCT MANAGEMENT
The difference between being a good product manager and a great on
Key lessons and advice from a Product Manager at Canva
Being a product manager at Canva has taught me to move fast and make high impact decisions that move the needle, even when there’s uncertainty. As we grow, it’s important to remain agile and flexible with our approach, but it’s not always easy to keep growing while maintaining the best of our startup DNA!
Working as a product manager in my previous roles, my primary responsibility was to maintain an ongoing user base. It was as simple as that. But everything changed two years ago. All I knew about product management was turned upside down when I joined Canva.
Not long after I joined, I realized that if I stuck to the traditional ways of doing things, I would simply be the bottleneck slowing us down. Startups demand quick iteration — the ability to build minimum viable products (MVPs) — and as such, they require leadership from minimum viable product managers (MVPMs). The value of a product is in what gets used, not simply what gets built. Every PM is focussed on maximizing value, both for our users and for the business-but the difference between being a good PM and a great PM at a startup lies in one’s ability to work in an unpredictable, often volatile, space.
Some of the key lessons I’ve learnt over the years:
- Solve problems collaboratively
- No problem is out of scope
- It’s necessary to have an impact, not to wait for perfect data
- Having a long-term vision is important, but making short-term plans is necessary
- Add process only where it solves a problem
Solve problems collaboratively, not top-down
In more traditional, established businesses, while there is some level of autonomy, most strategic decisions are top-down and driven by multi-layered management who are responsible for making the calls and drawing up the strategies that we as PMs then find ourselves implementing.
Mapping out the game plan at Canva has always been a collaborative process, where I’ll find myself working alongside the main stakeholders, experts within industries, and the founders-often all at once.
This ethos of collaboration is also brought to the team. It’s important to bring back a problem (not a ready-made solution) to the team so that they are involved from the start. Pick an engineer and a designer to kick off with, and share the full context with as much color about the problem as you can include, such as all the relevant constraints (time, people, money, and tech). Then work with them to brainstorm various solutions and test these out.
The advantages of implementing collaboration are:
- empowering everyone in the team to suggest and make product changes-everyone is a product owner;
- creating opportunities for creative and diverse thinking;
- enforcing a quick feedback loop between users and the team;
- building solutions that are likely to be feasible from the get-go; and
- in the case of implementation, the team are empowered to make a lot of decisions themselves since they have already all the relevant knowledge.
A recent issue I presented back to the team was that our users found that editing large, printable designs such as posters, resumes, presentations was difficult to do on a phone. We received some feedback saying they weren’t able to tap on or select small elements in their designs, had difficulty in aligning things and wanted to zoom in to see more details.
Along with the feedback, I presented the team video recordings of the users trying to edit large designs. After brainstorming solutions, we came up with a bunch of improvements such as making the screen tappable area expand in ratio to the element size, better snapping and more sensitive resizing behaviors. In the end our solution went through a few iterations taking into account user feedback-and we were then able to ship an awesome feature set.
No problem is out of scope
In a large business, usually, several people are responsible for different parts of building and shipping a product. At a startup like Canva, you have the opportunity to change elements and solve problems at various stages across the entire end-to-end cycle-from our landing pages to the signup screens, the editing tool, and downloading the design screens. There is no part of the product that is out of your scope as a PM, and very few hard limits to what can be done with the product. This means you are always empowered to think big and solve a problem holistically with the aim of improving the full end-to-end user experience.
In a large company, there are various roles responsible for different parts of product development.
- Scrum masters are responsible for the day-to-day task organization and removing blockers for the team.
- UI designers are responsible for creating the visual effects such as buttons, icons, etc.
- UX designers are responsible for creating the product workflows.
- QA testers are responsible for testing the feature and raising bugs.
- Tech leads are responsible for ensuring the code written meets best practices. They could also be responsible for ensuring a feature gets into the build pipeline and then to production.
And the list can go on…
At a startup, you could potentially be doing all of this yourself-often at the same time. I remember spending a couple of days testing the iPhone app, while raising bugs for every release and simultaneously acting as a scrum master for the team. You’ll find yourself juggling a lot of different roles at the same time-whatever it is your team needs you to do.
The startup environment therefore requires a different type of PM to a big business. Because there’s always so much in the pipeline, you have to constantly prioritize what you can do in order to move the team and the company forward, i.e. what is the minimum amount of work that can have the highest impact.
Get quick validation, not perfect data
Working in a fast paced environment means there isn’t always lot of time to sit down and spend long hours researching. Often it’s easier or more efficient to ask friends or family to test your product, “dogfood” it within your organization, or use usertesting.com to get quick validation.
The quickest thing to test is usually a prototype- at Canva, we use Invision and Principle to create click-through prototypes and test them. This may not always provide you with complete validation but gives you a starting point from which to base your decisions.
It’s important to get comfortable with using incomplete user data, and rely on your intuition to make small, quick decisions.
Also keep in mind that it’s easier to ship and validate small changes rather than larger features. Always think about how you are going to ship an incremental UX flow-what is the smallest change that can prove that a feature adds value for our users and how can you build on that?
At the end of the day you can have security in the thought that as your product and startup grow, so will your data and the opportunities for user research and testing.
Optimize short term efforts, but have a long-term vision
As compared with most other businesses, the nature of a startup is such that while you have a clearly defined vision, frequent change is the norm. As such you won’t find yourself planning more than six months into the future. This doesn’t mean that we shouldn’t or don’t have any long-term vision- in fact, having a long-term vision of what the product should look like in 12 months is crucial to making sensible short-term decisions and optimization. What is does mean, however, is that you can always choose to delay certain decisions.
For example, one of our early objectives was to launch Canva in 20+ languages. But learning from our team’s experience on Web, rather than tackling that seemingly impossible feat all at once, we decided to focus on introducing one new language first-Spanish-and planned just enough to launch this.
Because of this change in direction, we were able to pilot things with one language, which informed the processes we then set up to launch and manage 20 languages, such as:
- setting up a regular translation process for when we add new features;
- hiring someone to make App store graphics regularly in the new languages;
- hiring ASO (App Store Optimization) experts for the new language markets; and so much more.
The process of translating our app into Spanish was unchartered waters for us. So focusing on just one language meant we would be able to use the learnings from this launch to inform our scaling decisions down the line.
As such, today Canva is available in 108 languages and have a growing global team.
Add process only where it solves a problem
Two and a half years ago we were four engineers, one designer, and myself on the Mobile team. We used to sit at the same table and talk to each other multiple times throughout the day. To kick off a new project we would only need a single document outlining the ‘what’, ‘why’, ‘how’ and the ‘user happy path’ UX flows. This was a living document that was used as a reference throughout the project. Everyone added details to the document as required-to record decisions being made or to specify analytics and so on. It was sufficient and met the purpose of aligning everyone throughout the project.
As the team grew to more than 25 engineers, three designers, and three product managers; we needed a lot more documentation and process.
- A project strategy doc. This describes the ‘what’, ‘why’ and ‘how’ to bring all the stakeholders into alignment.
- A functional specification doc. This describes different bits of the UX including edge cases. This was necessary to get a shared understanding of the features when they got a bit more complex and had multiple flows or touched many screens.
- A technical design doc. This describes the big architectural changes, libraries required, and any other big code changes that need to be thought through. This was needed as the engineers implementing the features were likely new to the codebase and did not have full knowledge of how their changes might affect other parts of the app.
Each document was written to solve a particular problem within the team or meet a certain purpose.
Similar to writing valuable documents that solve problems, aim to only add a process or structure where it solves a problem. Inevitably adding processes can slow things down and in an environment that needs constant adapting and pivoting, it’s logical that we delay this until it is deemed completely necessary. When the mobile team was small, we used to do ad hoc App releases whenever we were ready to ship something valuable. That meant that App releases could be one week apart or up to eight weeks apart.
As a team we decided that we wanted to get into a cadence for shipping some value to users on a more regular basis. We agreed that it wasn’t necessarily features that we wanted shipped but smaller things-such as bug fixes or performance improvements-that had a huge impact for our users. As the team grew, we also had more capacity to ship more things. At this point we decided to implement a fortnightly release process. To start off we kept things simple-we documented what happened as part of an ad hoc release and put in place a rotational ‘Release Cop’ role to follow that script every two weeks.
Since then, we have standardized the release process a lot more, automated many parts of it and built in things like writing a ‘What’s new?’ user-facing message, importing string translations, phased rollouts and so on.
NOTE: We did not set out to create the perfect release process upfront, and all of the above examples were created over time, as and when needed.
Allows us to still ship bug fixes and small improvements.
Final thoughts
Being in the constantly changing environment of a startup can be exhilarating and an amazing opportunity to learn something new every day. I’ve learned to be flexible, deal with uncertainty, and make quick, high impact decisions that have moved us closer to achieving our vision of empowering everyone to design anything and publish anywhere. As Canva grows, some of these skills will not be as important any more, as more information and data become available and we put more processes in place.
However, the mindset of doing the number one thing with the highest impact will always be relevant. This is a strong part of the culture at Canva and continues to help us move as quickly as we can. In today’s world, where staying ahead is one of the keys to survival-I challenge you to think about how you can bring this mindset to your work.
How to land a job as a product manager in a startup
- Understand the problem. Always think about who the users are and what problem a startup is trying to solve for them. This comes down to doing your market and user research, and of course-also using the product itself. Take it a step further and propose how you would approach fixing that problem in even better ways.
- Demonstrate your ability to work with engineers. Engineers are your daily partners who will help you ship value to users. Being able to understand the tech stack and communicate with engineers in their language is one of the most important skills to demonstrate in a job interview with a startup.
- Show your bias towards action. Your value as a product manager lies in your ability to ship new products and features to users quickly. Always keep the big picture in mind but then figure out the smallest thing (MVP) you can ship to users that will help validate the feature and get quick feedback. There will never be enough data and validation before shipping-so continuously build, ship and test.
For more details on our current job openings, visit Canva’s careers page here . Know someone who would benefit from reading this article? Why don’t you share it with them here:
Originally published at https://product.canva.com on September 11, 2018.
