We’re thrilled to share that Roadmunk made the 101th spot on the 2020 Report on Business ranking of Canada’s Top Growing Companies.

Canada’s Top Growing Companies ranks Canadian companies on their three-year revenue growth.

Over the past few years, Roadmunk has been on quite the journey. Last year, we were awarded a spot on Deloitte’s Technology Fast 50 — we shared a few reflections on how our 2018–2019 year went in this Medium post.

While we never imagined the world looking quite like it does in 2020, we’re excited that we launched our feedback and prioritization features this past spring. This makes Roadmunk an end-to-end roadmapping tool that enables users to capture customer feedback, prioritize what to build next, and use boardroom-ready roadmaps to communicate their strategy.

To view the full list of 2020 winners, and accompanying editorial coverage, visit tgam.ca/TopGrowing or pick-up a copy of the October issue of the Report on Business Magazine.

We’re so honored to have made Canada’s Top Growing Companies list and are looking forward to the years ahead!

Roadmunk wins spot on The Globe and Mail’s Top Growing Companies was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Roadmunk teamed up with Women in Product Chicago for their first virtual discussion — From feedback to future: How to pivot based on new customer needs.

Priya Mathew Badger, SVP of Product at Codeverse, and Maria Pereda, Director of Product Design at Roadmunk, talked about how to use the changing needs in customer feedback to successfully pivot and retain customers.

We’ve pulled out some highlights from the conversation if you’re tight on time but we highly recommend tuning into the full conversation between Priya and Maria — it’s jam-packed with helpful recommendations and insights.

Highlights
(The highlights have been condensed and edited for clarity.)

Priya’s PM background & Codeverse (1:52)

Maria: Can you tell us a little bit more about yourself and how you got into product?

Priya: I started my career in economic consulting, so not in tech at all, but I was always super passionate about technology. I loved all the Google products. I used to submit future requests online to Gmail and Google docs as a user. And then I was lucky enough to join the Google apps team in 2010 when the product was really taking off. It was an exciting time to be there, as we were just starting to monetize and growing to millions of users. I would say one of the best things about that experience was just getting to see lots of different product teams because Google apps is a suite. So, seeing Google docs, Gmail, calendar, all those different teams and how they operate and how they did things, some things similar and some things different in terms of how they manage their products.

After Google I actually went back to business school at Northwestern, and I got a dual degree in the MBA program and the engineering design program there, and it was a really cool way to just build design thinking skills. And I started at eSpark in Chicago afterwards and I love being here in Chicago and part of the community here, especially with the strong Women in Product network we have. And eSpark built a reading, math and writing software that we sold to school districts. Google apps was a B2B product, but it was built on top of a consumer code base eSpark sold to schools and nonprofits. Our end users were young kids in K through eighth. So my first time designing products for kids as young as four and five, which was a lot of fun, but also some new challenges.

And then at Codeverse, we build a platform that teaches kids coding from six to 13. And we’ll talk a lot about that. But Codeverse is a consumer company. So we’re selling to parents who are signing up their kids. And so, I’m still in that education space, but now I’m working on the consumer side, which definitely has some different aspects to the product development, than when you’re working with organizations or businesses. So I have gotten to see some different experiences, be at big companies and smaller startups.

Pivoting from a 100% in-person product to 100% virtual (4:24)

Maria: So up until COVID hit, Codeverse was a 100% based on in-person events and classes, right?

Priya: So our business model was we had physical retail, like brick and mortar studios, that parents would sign their kids up for after school classes, camps, events, birthday parties. And at those, they would be using our online coding platform and the kids would be learning to code with our software. But we felt like that was sort of the consumer behavior. At the time, parents are used to signing their kids up for after school activities. And it was a good business model for us to get started with the company. And so 100% of our revenue was coming from that. Obviously with COVID, we ended up shutting down our studios during that time and really had to rethink the entire business from the ground up in terms of what does the business model look like?

Maria: How did you handle that? How did the entire product process change and how did you handle that pivot?

Priya: I think one of the things that helped us was we have a very strong leadership team and we’re a small company. So we were able to kind of all get in a room and we saw it coming, obviously. You see what’s happening overseas. We had great board members who kind of gave us a heads up, like schools are going to close. You’re probably going to need to close your studios. We talked about it even in our Q1 board meeting and so we were thinking about it in advance. Luckily, we do have an online platform and we knew that we had great assets in terms of our instructors that teach at the studio. So our product, we had already considered was virtual tutoring, one-on-one sessions. And we’d already sort of done a little bit of the groundwork, but this just super accelerated the timeline for that.

I think a lot of the changes came from just that absolute focus on this is the product that makes sense for us during this time. And we all need to go all in on it. And in some ways, we kind of joke that the studios closing was the only way we could have made virtual tutoring successful as a product. Just because it allowed the entire company and all of our resources to be focused on it.

Conducting customer discovery when you can’t do it in-person (6:54)

Maria: Before then, all your feedback collection and understanding insight was based on going in-person and observing and interacting with both the parents and the students, how do you do your customer discovery now?

Priya: Yeah. And that was one of the things that attracted me to Codeverse and I loved about it — was it is really magical to be able to be sitting in a room with your users and just observing them as they’re using it and come kind of in and out of the experience. But I will say that I actually think in some way, doing things virtually has made it easier because we record every session that kids are doing in our online sessions. And so I can go back at any time and watch those recordings and rewind and watch some again, where it was just much harder to do in an in-person setting. And we also started a parent survey where after every session we would survey parents about their experience and their kids’ experience. And that just gave us like a really rich data set that we hadn’t had before.

I think when parents are thinking about the product as the online experience, they’re more comfortable giving that feedback in an online way, versus in the studio, a lot of the feedback came in more anecdotally through conversations they’d have at the front desk or with our staff. The other thing that I’ve done that I think is a little bit new, is joining some Facebook groups, like moms groups and doing kind of social monitoring. There’s just a lot of challenges facing parents right now. And they’re and everyone’s talking about it. And so it’s been interesting to see some pretty direct questions in some of these moms groups about the problem and opportunity that we’re working on.

Handling large amounts of feedback and turning it into something actionable (9:15)

Maria: So now you’re getting tons of information, which compared to before is just the volume sounds incredible. How do you handle that? How do you absorb that and turn it into something actionable?

Priya: I think even in the case that you have a lot of uncertainty, you always need to have some kind of plan and some kind of focus. For us, we kind of came up with what are the objectives that we need to do? And part of it was just transitioning. So how do we get our current customer base to move over to this new platform? And that was our first focus. And then once we got a majority of those customers to move over, then the next focus was how do we attract new customers and how do we grow that customer base? And then now we’re really focused on retention. As well as obviously everything else continues to be important.

I think when you have those focus areas, you’re able to better figure out where’s the feedback that you need to pay attention to. When we were focused on our existing customers, it was a lot of looking at that parent survey, watching those initial videos and figuring out what about this experience feels different than the studio in good ways and in bad ways. And now that we are online, how do we make sure that our experience still feels premium? And how do we make sure that it’s still on brand for what we want, which is the best educational experience for kids learning to code so one example is, when we first launched virtual, we had small group classes because we do classes in the studio. We figured we’d do classes online. We made them pretty small.

They were only three or four kids. But we just saw that, that wasn’t the premium experience when you were online. Because there were kids of multiple ability, levels and ages. In the studio it works because the guide can kind of go along and work with each kid. But in the online setting, it was much more difficult to manage. And so at least in the beginning, we decided that even though it was more expensive for us to do it this way, we would give every studio member a one on one session in exchange for every class they would have had at the studio, which is obviously much more costly operationally.

But I think was worth it just from that goal of really providing customers the value that we believed met our brand. Now later, we ended up kind of launching a virtual camps product, which does have a group setting that has different programming and different techniques that we added in order to manage that group setting. And then now we’re kind of going through that same process of watching videos from camp and trying to figure out where are the things that we need to troubleshoot and improve on.

Getting alignment on implementing feedback (12:15)

Maria: So that’s interesting, you’re talking about this bet, these premium experiences that operationally are much more expensive. How do you bring along the rest of your company in a bet like this? How do you have the confidence that maybe this is the right move to make?

Priya: Some of it is trial and error because we had a mix. We had one on one classes and we had group classes. And so we knew that the one on one sessions were getting amazing feedback and the group sessions were a little bit mixed. And so some of it was just bringing that customer feedback, those recordings, those quotes from parent feedback to the light of the leadership team. And there are other people who are hearing that feedback, not necessarily from the product perspective, but from the people who are working in customer service for parents, or the sales team who might be following up and trying to convert that customer. So it was coming from multiple angles as well. But I think the real thing was just being okay making a big bet and knowing that you don’t know if you’re right.

One of the things our CEO said was we’re kind of being faced with a series of somewhat impossible to make decisions. At the end of the day, we just want to be able to look back and be proud about the decisions that we’ve made and feel like they reflected the values of our company. And so that was always a guiding function for us. One of the things we did was we closed a week or two before the state home order, which we could’ve made money off of the studios being in session, especially cause parents were desperate. One school was closed. So there was a gap between when schools closed and when organizations like us would have been required to close. But we felt like the right thing to do was to close and protect our staff and protect the kids and just move faster to virtual. And that’s what we did.

The other decision we made was not to lay anyone off, which required some really tough budget and financing questions around, like, how do we make the space for this? And how do we find a business model that will work that can support keeping everyone on staff? So there were a lot of decisions that I would say we didn’t know that they were going to work out, but they reflected the values and the brand of the company and they felt like the right thing to do. I think they were also all things that you can reverse and change over time. At some point you just have to go with it.

Priya’s advice for collecting user feedback for the first time (18:02)

Maria: What advice would you give to a company that wants to start getting customer feedback, but they don’t know how to do it?

Priya: That’s a good question. I think not trying to over-engineer it and just try to get something quick and dirty out there. For example, like we just made a Google form and manually texted it to every parent after their session. And then did an email blast and it was great for getting awesome feedback. Now that we’re trying to scale the program, we built in a survey model into our database and we’re going to have nice popups that come up after your session. But to just start getting that feedback, you don’t need a lot. You can just use the tools that exist for you. And then the other thing I would say is, most customers want to talk to you and give you feedback. Pretty much any parent I’ve ever reached out to.

The other thing I would say is, you don’t necessarily need to talk to people who are already using your product in order to get feedback. I’ve gotten really great feedback from people and Women in Product for example, just asking, “Hey, are there moms with kids in this age range that would be willing to talk to me about this?” And sometimes talking to people who don’t use your product yet, but are kind of in the market or in the persona is really helpful. Friends and family or professional networks can be really great grounds for that. Our company doesn’t have any formal process for doing discovery work.

I don’t think you have to necessarily ask for permission or get a budget. I think it’s all about just getting out there and figuring out where’s a good place to start.

Quantitative vs. qualitative feedback (20:50)

Maria: What would you say to companies that say, “we’re data driven, we don’t need to talk to people because we have all this data.”

Priya: We look at the data all the time about what is the usage and the actual behaviors of kids and parents on the platform. And that is another benefit of having everything happening online, is that we can really like tie all the activities together. I always think about it as, the data tells you what happened, but talking to users tells you why it happened. And it can be really hard. If I look at the data and I can see Oh, it looks like kids are engaging with this type of activity, but nobody’s doing this other type of activity.

I know that that happened, but I don’t know why it happened. And so that’s where I think talking to users and observing them gives you more insight into that. And then I also think sometimes things just don’t always show up in the data or they will show up, but they will show up much later than when you want to know about it. And especially considering how quickly we want to be able to react to issues when we’re building this totally new business from the ground up and we have a lot of pressure for it to succeed, because it’s entirely replacing the revenue that we lost. So one example is, we were kind of using a compilation of tools to get these one-on-one sessions off the ground.

So we use Zoom, we use Calendly and then we had our own internal systems and it did work at the beginning. So the data would point you to the direction of this is all fine. But if you look at the customer feedback, they were just these kind of hints and rumblings of I wish this was integrated into the product, or Zoom doesn’t work for me, or I’m concerned about Zoom privacy, or it was hard to get set up. And so even though customers often rate us a five out of five on their experience, we could still see these comments coming up frequently. And then at the same time, it was also really costly for us on the operation side to just pull all these tools together and make them all work. So we ended up investing in virtual video integration.

So now we have video integration right into our platform when kids log into our coding platform, they see the video of the guide in the corner and we don’t have to use Calendly or Zoom anymore, which we just rolled out last week. But if we had only been looking at the data, we would have probably not seen that until customers were starting to cancel or seeing it in retention and then we’d have to dig in later. So that’s something that you can get early signals on what your users’ needs are.

Prioritizing feedback (23:57)

Maria: I want to get back to prioritizing customer feedback. Do you use any frameworks specifically or how do you manage to decide what moves the needle, what doesn’t move the needle. what do we invest in, what do we not invest in?

Priya: One of the hardest things you have to do as a product leader is make those tradeoffs. I always say the best framework to me is starting with really clear company goals and strategy. If you have that, then the product needs sort of uncover themselves. Because you’ve leaned into what are the most important things for us to accomplish as a company? And then what’s our strategy for how we get there? And then from that you can derive, okay, based on these goals, what does the product need to do? Or how does it need to change to be able to meet those goals? Obviously as you’re doing the discovery and the process of building that solution changes over time. But you at least know what goals and what you’re aiming for.

And I find like that framework works really well because it just provides a filter and focus. The challenge if you use another framework, people will weigh the impact versus the effort or something like that. And you have some kind of matrix for that. I think it logically makes sense. The problem is you could have an infinite amount of ideas and you’re going through this exercise that feels almost mathematical about ranking all of these different ideas. But at the end of the day, you don’t really know the effort until you know the solution, which you don’t know until you start the discovery process and you actually start building it. There’s just too many things to actually be able to come up with a rank order for all of those. You need to have the company goals and strategy side in order to filter down that list.

Rapid fire questions

(26:55) What’s the one piece of advice you would give a product manager or leader who’s trying to navigate how to adapt to this time?

(27:58) If you could give Priya from February a piece of advice, what would that be?

(30:45) If you had to recommend a book to anyone, it can be a product management book, it can be a design thinking book — what would it be?

Speaker bios

Priya is the SVP of Product at Codeverse, a Chicago startup working to teach a billion kids to code through its interactive coding platform and studios designed for 6–13 year olds. Priya previously led the product and design teams at eSpark Learning which delivered personalized learning to kids in K-8. Prior to eSpark, Priya worked at Google on the Google Apps team. A glutton for learning, she graduated from Dev Bootcamp and received a dual degree MBA and Masters in Engineering Management from Northwestern.

Maria is the Director of Product Design at Roadmunk, a SaaS product that enables companies to visualize their strategy and align as an organization. She is building Roadmunk’s first design practice and laying the foundation for a user research program to guide future efforts. Maria has a strong track record of setting up design practices from the ground up, where she focuses on building foundations for research, strategic design thinking focused on user goals and business outcomes and creating strong partnerships with product and engineering.

Prior to Roadmunk, Maria served as Senior Director of Product Design at Schoology, a leading Edtech company in the K-12 US market. Maria established Schoology’s first design practice and elevated design culture within the organization by making numerous improvements in process throughout the product development life cycle. Past experiences include Group Director of UX at Critical Mass, leading work for the Citi Global accounts in Toronto and New York. She’s also held design leadership positions at GE, where she helped establish a design Center of Excellence, and Fry, an e-commerce startup later acquired by Oracle.

In 2018, she took an oath to never buy clothes again, and has been making her own since, with variable success.

About Women in Product Chicago

Women in Product Chicago is an organization started several years ago out of the Bay Area devoted to increasing diversity and inclusion in product roles. The Chicago organization started over 2 years ago now and they’ve been going strong ever since thanks to their strong local community.

They would love to hear from you. They’re looking for ways to help their community continue to feel connected. And they’re always looking for speakers and new event ideas. Find them on womenpm.org, click on the Chicago community and sign up for their weekly newsletter — or email them at chicagowip@gmail.com for more info.

About Roadmunk

Roadmunk is an end-to-end roadmapping tool. With the new feedback and idea management suite: centralize customer feedback, create a customer-validated idea backlog, systematically surface high-impact ideas and promote ideas to your roadmap.

Try a roadmap template, which include technology roadmaps, scrum roadmaps, agile roadmaps and lots more. Choose from 35+ ready-to-use roadmap templates and product roadmap examples: https://roadmunk.com/roadmap-templates.

From feedback to feature: How to pivot based on new customer needs was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today is a special day in Roadmunk history — so strap yourself in, because it’s humblebrag time.

I’m proud to announce that our company made Deloitte’s Technology Fast 50. It’s Deloitte’s way of honouring the 50 Canadian technology companies with the highest revenue-growth percentage over the past four years. We scooped up the 12th spot on the list.

But the celebrations don’t end there. Roadmunk also ranked № 96 in Deloitte’s Technology Fast 500, its annual ranking of the 500 fastest-growing technology companies in North America.

These two awards from Deloitte mean a lot to the Roadmunk team. It gives us a chance to celebrate our growing global customer base, as well as our Canadian roots in Toronto and the Kitchener-Waterloo area, where we continue to grow our team and innovate our product.

It’s a big win for us and we’re extremely proud of this achievement.

Last year, we published this medium post going over Roadmunk’s biggest challenges, surprising delights + hard-knock lessons since 2013 (the first year of Roadmunk’s existence). So we thought we’d update it with the years 2018–2019 as part of our celebrations.

2018

The hardest part: Walking away from a fundraiser with huge cultural implications.

Being away from the business to meet and vet investment firms had one unfortunate side effect: it took the leadership’s attention away from the work being done by their teams.

We came back to a lower eNPS (Employee Net Promoter Score), which was late in the year when teams are sprinting to ship, sell and operationalize before heading off for the holidays. Thankfully, the team here has the grit and perseverance of salmon swimming upstream, and we came out stronger on the other side.

This did result in more work for leaders in the long term because we had to fix those issues that were born out of our absence. During this recovery process, we realized that we were in a stronger business position, so we walked away from that potential fundraising partner (they, ultimately, weren’t a good match for us).

We were able to successfully bootstrap the business ourselves without outside capital.

The most delightful: We were cashflow positive.

The average SaaS company — at a similar stage to Roadmunk — has likely raised more than $20 million dollars. And we’ve raised a tenth of that. This is thanks to our heavy investment in a flywheel business model that is driven by product-led growth and an excellent customer success team that provides world class service.

This all led to the addition of over 1,000 new customers in 2018 and put us in a cashflow positive position — something that I’m incredibly proud of the team for.

The biggest lesson: Find a leadership team that builds deep trust with one another.

I was recently listening to Ben Horowitz on a podcast and he said that “If most founders knew what they were getting into, they would never start a company.”

It’s hard not to empathize with that statement. but it sparks an interesting question: why do founders continue? For me, I wake up excited because I get to work with an ambitious, talented and energetic team every single day. We are solving hard and challenging problems. It can be very stressful.

But we learned that the amount of work and stress needs to be distributed among a strong leadership team or all that burden will lead to paralysis and a team won’t be able to scale.

Extract the time to find those people and invest in them. Spend the resources you need to find those people and the business moves faster.

2019

The hardest part: It’s tough to keep up with the demand for employee feedback.

Giving feedback is, without a doubt, one of the hardest things to do — even if you’re a skilled manager or leader.

A growing company = new layer of middle management and that = more 1:1s. And people are eager for feedback so that they can improve.

As leaders, we’re constant getting “I want more feedback!” as feedback. But it’s difficult to position and deliver critical feedback so that it lands (yeah, you probably need to deliver it multiple times) and it’s even more difficult to keep the recipient of said feedback accountable to it.

We completed management training this year (and it helped) but I do believe this is something that will continue to be a challenge as we scale.

The most delightful: Sending the team to work from beautiful Medellin, Colombia (which we wrote about here).

On top of that, another highlight this year has been watching the team solidify and grow to 110 people, which has allowed us to invest more time in deepening our relationships with our customers (read: a lot more plane rides for on-site visits) and getting to know them better.

This has allowed us to get a stronger understanding of common user pain points — and now we’re building a new feature set that addresses those headaches (spoiler alert: we’re introducing feedback and idea management into Roadmunk next year — our biggest release to date).

The biggest lesson: Our go-to-market plan had to change once we tapped into new data.

We saw that having a salesperson talk to a prospect before they become a customer is important. That’s because spending money requires having the right information, understanding how secure the application is, how Roadmunk will scale with that organization, and other questions that aren’t so obvious when you sign up for a software product like Roadmunk.

We had to balance being a demand gen, flywheel, customer-first/product-led growth organization with this new knowledge that sales has to play a bigger part in the user onboarding equation.

Looking ahead

We’re excited to continue on this growth trajectory as the market for product management tools matures. This is still a nascent space and no clear leader has emerged. We’re investing a lot in our people and building a feature-rich platform that constantly solidifies my confidence that our company is positioned to win the market.

I’m excited to see what the next year (and beyond) will bring!

Roadmunk wins a spot on Deloitte’s 2019 Technology Fast 50™ was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Beauty is in the eye of the beholder, but with product design, it’s also in the hands (and experience) of your users. Product design isn’t just about making your product look aesthetically pleasing. It’s also about helping your users solve a problem and achieve a goal using your product. However, when a product gets bigger and more complex, it’s inevitable that cobwebs start to form in the corners–dusty old modals, out-dated icons and even an aging colour palette. Aesthetics that were approved years ago, may look archaic and are signs that design debt has started to accumulate.

What is design debt?
Design debt is very similar to technical debt. It refers to the extra time that needs to be allocated to your team when going back to fix something as a result of prioritising a faster product launch over thoughtful design. Technical debt is invisible, but painful, and trickles through the organization. Every developer is affected and so is the shipping speed.

In comparison, design debt is at the expense of a different audience—your user.

The accruement of design debt can threaten a product’s brand just through poor UX. It can pop up like sinkholes that form slowly at the base and get larger over time. Or they can be baked into shiny new features as gaps in the execution because a faster shipping time was prioritised over the quality of design.

An example of design debt is the inconsistency between web pages or a disjointed interaction for the user on mobile versus desktop. Mismatched colours, typography and spacing are also signs of design debt, which contribute to a user having a chaotic experience when using your product.

What’s the cost of design debt?
In the most severe cases, design debt can turn customers away from a product. When users experience lousy UX, it makes them trust a brand less, even if the product is of top-notch quality. Users might become frustrated with their experience and give up on the product altogether. Despite the saying of “If it ain’t broke, don’t fix it,” what you’re product team is shipping isn’t just a mere product, but an experience. This experience is an interaction with another human being that becomes an incredibly nuanced conversation filled with subtle cues. So even if it’s working and not technically broken, it may need a tune-up.

A huge challenge within a product organisation is finding a way to articulate design debt as a business case to your team and stakeholders. As difficult as it can be, product designers need to fight for it as a priority and know when it needs to be placed onto a roadmap.

Below are some tips on how product teams can avoid design debt.

Step 1: Set the design vision

Know who you are and who you want to be. Design leaders should have a clear vision and key goals that the team can work toward.

• Solidify your company brand

Your company’s brand should be aligned from the design to the marketing. Make sure you’re distinguishing yourself from others.

• Understand your users and your product

Be very sure of what you’re selling to your users and what problem it helps them solve! If you’re positioned to be a video player, then that’s what your customers will come to you for. They’re not looking for a message board or online forum.

• Market differentiation

In the product world, it’s important to know your competitors. Even if you’re offering a product that solves the same problem, what makes you unique will drive the vision.

Step 2: Know what measures to use to defend against design debt

Design debt accumulates when there isn’t alignment or clear goals on the design. However, it can be worked on through preventative and reactionary processes.

• Have a style guide

One preventative measure is to have a style guide for designers. This way, there’s a standard of quality that’s being tested, measured and achieved.

Another practice to defend against design debt is to empower everyone on the product team to be a designer. What this means is for the design leader to evangelise a solid design vision. When an expectation is set, design debt then becomes everyone’s responsibility.

• Always remember the Scout’s rule

A reactionary approach to design debt is to follow the scout’s rule: “Always leave the campground cleaner than you found it.” When applied to design, always be on the lookout for an easy win. If you spot something that can be fixed, clean it up while you’re there.

• Evangelise the importance of design

Making design debt a priority is another reactionary approach. On your product team, get your devs and PMs involved into the mindset that taming design debt should be a priority. A good way to start making a business case for design debt is to use data to prove that the UI is clunky. If a feature was designed to solve a problem and the users can’t discover it because of the design, then it’s very obvious that something needs fixing.

Don’t be afraid to fight for cleaning up design debt to be part of your product organisation’s roadmap. It’s just as important as shipping a new feature. When confronting design debt, be honest and take a step back by experiencing your product as if you were a customer. It can be easy to become blind to fault.

Don’t be embarrassed about your design debt either. Having it doesn’t mean you can’t run your company or have a strong business. Recognise that design debt is a relationship that needs to be managed through awareness, prioritisation and execution.

Dealing with Design Debt was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

In March 2019, right when the stubborn Canadian winter was in full swing, the Roadmunk team got on multiple connecting flights and embedded itself deep into the sunny Andean mountains of Medellin, Colombia for two weeks. The big goal for this trip? To strengthen Roadmunk’s values of starting with empathy, building with balance, and having fun together.

But first, I’ll rewind a little bit to why it all really started.

Roadmunk has two offices in two separate cities: one in Toronto, Ontario, and one in Kitchener, Ontario. It’s hard to bring these offices together for a significant period of time during the year, but we try our best.

The blueprint for the trip to Colombia, then, was this:

1. Bring these two growing offices together in a sunny country.
2. Create the perfect environment for Roadmunkers to share meaningful, unique experiences together.
3. Use those experiences to create a precedent for future work interactions and collaboration once everyone gets back to Toronto and Kitchener.
4. Drink a ton of freshly-plucked-out-of-the-earth Colombian coffee and freshly squeezed tropical juice.
5. Watch #culturemagic happen as we nurture the values that Roadmunk was built on.

This might sound like hyperbole, but the results were truly unlike anything we could have planned using spreadsheets, shared docs, confluence pages and slack channels. People organically planned all sorts of activities, new work initiatives were born, and many were inspired to add new wellness activities to their routines once they returned to Canada.

You might be asking: “Is this really how it all started? What about planning? How did you get nearly 40 people from Canada to Colombia? How did you know it would be alright? What about safety and health and productivity?”

Hold on to your seats. We have answers.

The planning stage: An exercise in empathy

Humblebrag alert: This wasn’t the first time we took the team on a retreat to Latin America. Previously, we’d been to Costa Rica and Nicaragua, so we already knew that the next retreat would take place in an equally warm, sunny and, most importantly, affordable country. On top of that, I’d already visited the place where we’d be staying; a “digital nomad hotel” called Selina that specifically caters to travelling professionals.

So the main priority after picking the country and the hotel was to ensure there were no barriers for Roadmunkers to come along (unless, of course, they had commitments, pets and families that kept them from going). For starters, we made sure there were no technical barriers by checking the internet connection, that the working spaces were, well, working, and by ordering any special equipment anyone might need.

In terms of the cost, Roadmunk covered the accommodation, most meals, shuttles to and from the airport, and a few team dinners to some of the best restaurants Medellin has to offer. The only thing left for people to cover was the airfare and any after-work adventures.

Selina proved to be an exceptional working space. The staff was attentive and accommodating, and the facilities were beautifully decorated, creating a fresh, vibrant vibe unlike any other hotel in the world. It also offered spaces like a movie room where some Roadmunkers would watch movies and play video games. Selina also had free daily events taking place in-house: coffee workshops, salsa classes, Colombian cocktail classes, pub crawls and group trips to local events like carnivals and food festivals.

Part of eliminating barriers included making the most relevant logistical information available to everyone before going to Colombia. We did this by creating a centralized hub populated with everything people needed to know, therefore saving everyone time on research and reducing the amount of anxiety around the unknown.

On top of that, our planning team left no stones unturned. If anyone needed help checking in, making sense of the local transportation, finding an ATM or a supermarket, or arranging special meal requests, we had the Slack channels in place to assist with that.

Making it easy for Roadmunkers to come also included giving everyone flexibility around how long and when they wanted to stay in Medellin. You can only do one-week because you have a family/dogs/cats/a busy schedule outside of work? Sounds good! All we ask is that you make the most out of the experience.

For those who had to stay behind, our Social Committee planned two days of sister office bonding. The Toronto office travelled to Kitchener and stayed there for two days. While in Kitchener, people participated in a design ideation workshop, a “speed dating” exercise for asking rapid-fire questions about each other, and a night of bowling, pizza and chicken wings.

Planning the Colombia trip around our values of empathy meant covering the perspectives of everyone involved: this included those travelling to Colombia — or anywhere in South America — for the first time, seasoned travellers, those staying behind in Canada, those with a multitude of hesitations and concerns, and everyone in between.

This trip really showed me that Roadmunk fosters the culture it claims to have. I was able to see that Roadmunk’s values are centred around people and empathy. As a first time traveller to South America, I thought I’d be nervous or lost, but every minute of the trip was fantastic. It was invaluable to be able to share something like that with my fellow team members.

-Brandon Mubarak, Web Applications Developer

Building health-work balance

But what’s the point of going on a retreat to South America when we could have done that anywhere in Canada?

It’s simple enough. When you mix the ingredients of vitamin D, a teaser of the summer to come, and the dopamine release that comes with working in a new, beautiful, comfortable environment free of the usual hang-ups and commitments back home, the positives in two parts:

• A refreshed approach to the work you do every day,
• A chance to reflect on the way you balance that work with the rest of your life.

Lifestyle balance

Bypassing everyday time-sucking activities like commuting and cooking meals also opens up a time window for self-improvement. The trip to Colombia eliminated the usual shoving your way out of a packed streetcar during rush hour, ordering food from Uber Eats then feeling guilty about not cooking, and skipping yoga or workouts because getting to your local gym sometimes just feels like too much.

The only thing Roadmunkers had to do every day was wake up, take an elevator downstairs and eat the provided meals at the scheduled time. Teams were also inspired to sign up for local gym memberships, take yoga classes every morning at Selina, go for jogs in the lovely neighbourhood of El Poblado, and pool + spa days.

Having that layer of “adulting noise” removed from their day-to-day, and being able to experience the benefits of adding more wellness activities to their routine, inspired some people to get back in the groove of self-care and #healthyliving once they returned to Canada.

One of the benefits I got from this trip was the chance to think about my work-life balance. In Colombia, we were going to the gym together, waking up with the sun, having balanced meals three times a day. It helped me remember how important that is, and what a life with the perfect balance looks like. It was lovely!

-Alexandra Mierzwa, Operations Manager

New flexible environment = refreshed creativity

For some, working in Colombia had some unintended positive effects on their actual work. In my case, I spent most of my time having meetings with every single team member in Colombia. I wanted to hear about their goals, challenges and any feedback they had for me as a culture leader, the company and the way things are going for them professionally. I was able to take the feedback that came from those conversations, reflect on it, then act on it across the board once I got back to Toronto.

Others found themselves organizing ways they could improve the company culture back home. One of our test specialists in Kitchener made a strong connection with one of our Customer Experience team members in Toronto. They got into the weeds of what they do, the pain points of their jobs, they shared their wins and tried to figure out if there was a way they could support each other.

They came up with a cross-collaboration initiative for when they got back to Toronto: job shadowing — a type of peer mentoring where Roadmunkers could sit with each other for a day and watch what they do, learn about their day-to-day and how it fits in the broader context of the organization and across teams.

Some team members — like people working on highly output-dependent jobs like content creation and design — reported breakthroughs in problems they’d been stuck with for weeks.

Fun together

Here at Roadmunk, we value the importance of forming meaningful relationships with the people you work with every day. One way we foster this is by organizing monthly social events, Friday get-togethers, and weekly lunch-and-learns. But these are all organized activities that not everyone might be on board with every time they happen.

The retreat in Colombia offered an environment where things could happen organically. Roadmunk only planned a handful of team dinners, but the rest of the time, Roadmunkers were on their own. By opening up the field for people to get creative with what they do, how they do it, when and with whom, people had an easier time creating bonds with people they usually wouldn’t work with.

These best part? These activities weren’t just any pub night or bowling tournament. Remember how some Roadmunkers were in Colombia? An entirely new country with new food, new places and new faces to explore? Our team certainly didn’t forget. As soon as the clock stroke 5, or the weekends rolled around, groups of Roadmunkers would plan all sorts of outings.

Some of the highlights included:

• A few teams took day trips to Guatape, a small town where they climbed 700 steps to the top of an ancient and mysterious inselberg (where they were promised the “best view in the world” at the top)
• Another team visited the lush coffee fields of Antioquia (Colombia’s “Coffee Belt”), where they learned how the beans are grown, harvested and roasted by a local family-owned farm
• A few other teams rode cable cars to the top of the mountains that surround Medellin and watched the sun set over the city.
• Some took weekend trips to beach towns like Santa Marta and Cartagena
• Others were interested in the local history, so they took barrio transformation tours where they learned how the city has changed over the past few years
• And a lucky handful got to see Colombia’s biggest musical act J Balvin make a surprise appearance at La Solar music festival.

Experiencing these beautiful towns, learning together and having fun exploring culturally-rich, historically significant places as a group gave everyone a chance to add depth to their relationships with each other.

I was definitely a bit nervous about going to Colombia, as it was my first week at the company. Upon arrival, everyone was extremely welcoming, friendly, and included me in group excursions around Medellin, which was really nice! After my first full day in Colombia going to Guatape with a few colleagues, my nervousness ebbed and I wasn’t so intimidated by the week anymore.

Liz Papierz, Events Manager

To wrap things up: Fun is hard

In order to pull off a trip like this, we needed to have a strong vision. More importantly, we needed to have a strong belief in our core values. We had both, and so, launching that ship across such a vast, unpredictable ocean like an overseas retreat, was never fraught with fear or anxiety.

That’s not to say we didn’t learn a lot of hard lessons for the next trip.

We did a survey to gather people’s feedback and found that there were common concerns across the board that we intend to work on for the next retreat. For example, giving people more time in advance to plan and prepare (we only gave people a couple of months to accept or decline), planning more team-building activities, and finding ways to give back to the local communities we stay in, were some of the common concerns expressed by a few team members.

Doing something radically unique takes a lot of hard work. For this trip, we wanted to do something that loudly said: “We care about these core values and we want to raise the bar by a lot doing something big like a trip to another country.”

I might be biased, but I have a feeling we did that and so much more.

What our retreat to Colombia taught us about culture was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

A wise product manager once said:

When development asks a product manager for more detailed requirements, she should give them deeper domain knowledge.

In the first part of this blog, I covered why it’s important to approach product development with that mindset. In this post, I’ll dive into how to get the development team on board with what I call the right 80/20.

Here’s a scenario: A well-intentioned product manager has researched, defined, and broken down the problem space. She brings her prioritized set of problems to the team and their first response is this:

“That sounds great. So, what do you want us to build? We need more detailed specs before we can get started.”

Most product leaders reading this are probably nodding knowingly. This scenario plays out the same way nearly every time a PM switches from breaking down the solution to breaking down the problem. As soon as the PM stops handing the team “solutions to build”, they feel lost.

To development, it can feel like the PM isn’t pulling her weight on the team. Development may even escalate the issue to management, complicating her situation even more.

Helping development gain a deeper domain knowledge, rather than a to-do list, is worth the hard work. One of the biggest payoffs is that they slowly stop asking “So, what do you want us to build?”. Instead, they’ll become more motivated to reach a deeper level of empathy for the real problems faced by users, which in turn results in generating solutions that address the real core problem.

In my experience, it often takes several months before product teams start to reap the rewards of this systematic hard work and persistence.

So, how can PMs change everyone’s mind? It’s not easy, and it requires the involvement of the whole team. Here are three key messages to continually reinforce with the team and with the broader organization:

• We’re all one team
• Our North Star guides us
• Everyone is a designer

We’re all one team

Let’s get down to the basics. Product teams are employed because customers pay money for their product (or for their data). This might seem like a redundant reminder, but it’s important to highlight that without our customers, product teams would be out of a job.

We’re all on the same team. The customer is the boss. Ultimately, the team “reports” to the customer.

Every product development team is cross-disciplinary at Roadmunk. This means we have a combination of product managers, designers, developers and test engineers on each team. Why? The same reason you wouldn’t assemble an entire soccer team of strikers: you’d give up way too many goals.

Let’s keep using the soccer analogy. The striker will have a tough time scoring if nobody passes them the ball and the team won’t be very effective at defending if that same striker phones it in on defence. In top-performing teams, it’s hard to find a player who doesn’t respect and appreciate what their teammates contribute to the team.

This is what team success looks like. So why is it so commonplace in software to point fingers, toss demands over the wall and say “that’s not my job”?

I’d say one of the most important aspects of being a product manager is to act as the team captain. If product managers aren’t…

• promoting collective ownership,
• encouraging team cohesion,
• And focusing the team on what’s best for the customer above all else,

…then they’re failing both the team and the users. Making a sustained and conscious effort towards becoming a “team captain” who promotes those things is the first step towards building a North Star culture.

When the individual members of a product team understand and appreciate how their efforts relate to one another, they’re more likely to be on track towards scoring those goals.

Our North Star guides us

So, how do we focus the team on what’s “best for the customer”? To answer that question, product managers can look to their North Star.

What’s a North Star? Simply put, it’s the reason the product team exists.

When you ask a team why they exist, some teams will respond with “to deliver feature x, y, z by Q3.” It’s true for a lot of teams (but not all of them): feature delivery is one way to measure success but it’s short-sighted.

Would you rather deliver 5 “okay” features this quarter or 2 “awesome” ones? Most (not all) executives would take the team that could deliver 2 awesome features every quarter and they’d aim to replicate that team’s magic on another team in order to deliver more.

The trouble is that, without an alternative definition of success, the only measure of progress teams have is the number of features they shipped.

With a good North Star definition, the product team will ensure that every feature they ship actually solves the problem it’s intended to. Sure, they may ship fewer features, but 80/20 is about delivering value not “stuff”.

How do I define my team’s North Star?

If a product team has a vision and mission defined, that’s a good start. But the best North Stars also include a single quantifiable metric that represents the success of their mission.

For example, Roadmunk’s North Star metric is “alignments”, which encapsulates how well we’re enabling our users to align their organizations to the roadmap. Our teams have individual supporting North Star metrics that ultimately contribute to the company’s high-level North Star.

In my soccer analogy, the team’s North Star is the scoreboard. Without it, product teams are just kicking the ball around.

It’s amazing how quickly toxic behaviour melts away when people rally around a common aspiration. The North Star is your team’s purpose.

Everyone is a Designer

Going all in on the soccer analogy, the team’s strikers are expected to score goals. After all, that’s what they’re great at. However, that doesn’t mean that a midfielder or a defender shouldn’t take a shot at a goal if they have an opportunity to score.

Given that your team’s objective is to deliver the best possible solution to users, it makes sense to leverage every resource at your disposal to figure out what “best” means. Everyone on any given team has a unique perspective. The best teams, defined as the most collaborative, take advantage of that.

One of the best feelings as a PM is when the quiet developer in the corner of the room pipes up and suggests a killer user interaction that nobody else even thought about because they assumed it was impossible, too difficult or too expensive to build. That level of collaboration only happens when discussions start with this user-centred question:

What is the experience we want to deliver?

Using every perspective to gain this deeper insight into what makes the “best” possible solution for users is at the core of collaborative frameworks like Design Thinking and empathy maps. These exercises don’t just exist to create a bunch of personas — they’re specific tools created with the purpose of aligning the way entire product teams empathize with the problems users face. And when product teams gain this level of self-awareness, they’ll always score their goals.

Thinking like a designer allows everyone to reach an agreement on what ideas should be prioritized based on a collective sense of human-centred/human-first empathy towards users. This understanding requires teamwork in the purest sense of the word: meet with the team and talk about how they define user problems, lead workshops, and learn to ask the right questions before a discussion.

And most importantly, remember this:

In the most successful product teams, everyone is a designer.

Delivering the “right” 80/20: North Star Culture was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re a product manager, you’re probably grooming the backlog and prioritizing ruthlessly in order to deliver the best possible results. But chances are, with each passing release, you may not feel like you’re delivering as much value as you and your stakeholders would like. You’re not alone.

Your success as a software product manager has a lot to do with your ability to maximize the value delivered over time. Ultimately that means limiting the scope. More importantly, it means choosing the right scope. This is where we aim to apply the 80/20 rule.

The 80/20 rule, also known as the Pareto Principle, is a management principle that states 80% of the value of your output, results and achievements come from 20% of your combined efforts (time, resources, money). Within product management, the 80/20 rule means that you’re delivering 80% of the value of a feature to the customer with 20% of the effort, or in 20% of the time.

In reality, delivering 80/20 is easier said than done. The success of the delivery depends on a sustained and deliberate focus on defining the right problems, shifting team culture and managing stakeholder expectations.

Let’s start by getting into the weeds of defining the right user problems using this 80/20 approach.

80/20 Problem Definition

In my experience, one of the biggest differences between the average and top tier product managers is their ability to define and break down problems, not solutions. There are two main pitfalls that plague product managers:

• They don’t spend enough time defining the problem
• They break down the solution instead of the problem without realizing it

Avoiding these two pitfalls allows product managers to focus on what’s really important.

Let’s say we were to add a new commenting function to Roadmunk at the roadmap level. I should mention that Roadmunk has a commenting feature on roadmap items, but let’s say we didn’t have one already and we were approaching the problem from scratch.

When asked to define the epic for this commenting feature, some PMs might write: “users want to comment on the roadmap.” That would be restating the solution as a lazy problem statement. Saying “the user wants to have a discussion about the roadmap” is better but it’s not granular enough to effectively inform trade-off decisions.

These definitions don’t actually help us break down and prioritize the work. If we stop there, we end up scoping out “commenting” and then breaking down the work into stories and sprints that don’t address the real problem.

We can take that better (but still lazy) problem statement (“the user wants to have a discussion about the roadmap”) and break down the user stories like this:

• Leave a comment on a roadmap item
• Respond to a comment on a roadmap item
• Leave a comment on a roadmap
• Respond to a comment on a roadmap
• Surface comments in notifications
• @ mention users in a comment
• E-mail users about unseen comments

You might say: “It’ll be most efficient dev-wise to sequence them in this order and once I get through the first four I’d consider that potentially shippable. Great, we’ll stop there because that fulfills the 80/20 rule.”

Right?

Wrong! (possibly)

Why? Because it might not fully solve the problem. Customers don’t care about development efficiency or that they got half of a feature early. They’ll never use the feature if they can only complete half of their workflow.

The key lies in breaking down the problem, not the solution. Here are a couple of problem statements that come to mind instead. I should mention that these are just two out of many other possibilities:

• Stakeholders need to ask questions about the roadmap
• Multiple owners/collaborators need to negotiate priorities & resourcing

Now let’s say we determine that the first one, “stakeholders need to ask questions about the roadmap”, is the most impactful priority for our customers. The right 80/20 decision here would be to focus only on solving that specific problem (while giving the engineering team the vision for the end solution so they can make good architectural decisions).

An example of an 80/20 solution to address that priority could be:

• Leave a comment at the roadmap level
• Notify all roadmap owners and collaborators of any new roadmap comments
• @ mention other users

This breakdown allows stakeholders to ask questions about the roadmap and allows roadmap owners to respond to those questions. We’ve only chosen to implement a fraction of the scope but we’ve solved a whole problem end-to-end. Could the solution be more feature-rich? Yes, but now there’s an opportunity to iterate on this solution with customers in the loop or to stop here and move on.

Arriving at this 80/20 problem definition requires a lot of effort and thoughtfulness from everyone in the product team. But at the very core, it’s about maintaining a deep sense of empathy for what users are actually trying to achieve with any given feature.

By always breaking down problems and not the solutions, product teams can feel confident in knowing that their user base will always be happy with what they deliver.

Main takeaways

• Always break down problems, not solutions. Doing this eliminates the chance of writing lazy problem definitions that don’t actually break down and prioritize the right solutions
• Shift away from breaking down the work into stories and sprints that are missing the mark in terms of addressing the real problem faced by users
• Limit the team’s scope to include only user stories that address the core problem. Customers would rather have a complete 80/20 solution to their problem, which they can use, rather than half of a feature delivered early

Getting your team to speak in “problems” is easy on paper, but implementing this — and making sure everyone understands it — may require a new level of commitment from the whole team, especially within your development team. I get into the concept of an 80/20 team culture in the second part to this post which you can read here.

Delivering “the right” 80/20 was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m going to preface this list by stating (in my opinion) that the long-form content that currently exists on product management isn’t as great as the short-form — like the articles I previously listed out here.

So, the books I’m including in this list aren’t specifically about product management or written uniquely for PMs.

But they will help PMs create stronger team dynamics, lead more efficiently and improve productivity. These books have all helped me in my day-to-day tremendously, and I’ve become a more well-rounded product person / leader because of these readings.

If you like my book recommendations below, follow me on Goodreads for even more.

1. Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization

By Dave Logan, John King and Halee Fischer-Wright

Every company is a tribe — or a network of tribes depending on headcount. And the way that individuals operate as part of their tribe is really powerful.

In Tribal Leadership, the authors walkthrough how you can identify where your tribe’s culture lands on a the tribal scale (it goes from one to five). And they provide specific tools that you can use to elevate your tribe to higher levels.

NBA coach Phil Jackson actually used the research outlined in this book to transform the 1995–1996 Chicago Bulls into the only level five team in the league–and its dominant, winning force. He wrote about this in his own book Eleven Rings: The Soul of Success (also a good read).

This book really shines with its communication tactics. Now, when I encounter new people or new tribes, I can quickly categorize them based on the tribal scale and identify the mechanisms they use to communicate with each other and outsiders.

Check it out on Goodreads.

2. Pitch Anything: An Innovative Method for Presenting, Persuading, and Winning the Deal

By Oren Klaff

It’s not uncommon for there to be tension between a product manager and the sales team. But here’s the thing, a PM can learn a little something from a sales rep — specifically when it comes to crafting a message that persuades someone to do something.

This is a skill that can be very beneficial to PMs. We need to be able to tell stories that influence stakeholders and entire departments to align on / move towards one product strategy.

This book was written by a sales pro and it can help PMs frame the story they want to tell and tug on the right emotions to get the buy-in they seek.

Check it out on Goodreads.

3. Letters from a Stoic

By Seneca

Okay. This is a very, very old book but it really holds up. It was written by Seneca — born in 4 BC — one of the founders of Stoicism.

The book contains letters that Seneca penned to his pal Lucilius. He shares stories that really made me re-think how I should be approaching communication (in and outside of work) and how powerful kindness can be in every situation. Seriously, I was just walking around my apartment for days thinking of how I should have handled past conversations.

I recommend this book to all PMs. You will learn a new set of principles in regards to responding to common behaviours and interacting with your team. It will leapfrog your ability to lead. Trust me. Even if you apply just a small percentage of the book’s lessons.

Check it out on Goodreads.

4. Ego is the Enemy

By Ryan Holiday

Ryan Holiday used to be American Apparel’s director of marketing. And, in this book, he explores how your big ego is getting in your own way.

Holiday shares stories of how taking a pragmatic approach to business problems is much more efficient than finding a maybe-not-so-reasonable solution that only serves to make you look good.

I’ve applied a lot of his lessons to check myself and how I make product-based decisions. Sometimes, listening to what the data is saying over your own intuition (read: ego) is the best, most balanced solution to a product problem.

Check it out on Goodreads.

5. An Astronaut’s Guide to Life on Earth

By Chris Hadfield

Chris Hadfield is one of my heroes (and not just because we’re both Canadian). His whole life story is compelling. The man had a dream to become an astronaut and he faced a lot of adversity to make it happen. It’s inspiring.

But the part that is most applicable to PMs is this: in any situation, you can either be a “plus-one”, a “zero” or a “minus-one”.

Always aim for zero.

A plus-one adds value to whatever new situation they find themselves in. A zero is competent, has little ego and doesn’t get in anyone’s way. A minus-one just causes problems.

But a plus-one can easily become a minus-one if they’re ego gets the better of them.

Zeros listen, observe and share advice when it makes sense to — they’re like a plus-one that doesn’t have to tell anyone that they’re a plus-one. They’re the best people to work with. And I think zeroes make A+ product managers.

Check it out on Goodreads.

6. Wherever You Go, There You Are: Mindfulness Meditations in Everyday Life

By Jon Kabat-Zinn

This is probably the book that I gift to others the most. It’s a little niche in that it will mostly resonate with people who want to practice mindfulness in the workplace.

This book stands out for me because it was written by Jon Kabat-Zinn. He’s a scientist, researcher and founder of the Mindfulness-Based Stress Reduction Clinic. He has been analyzing the brain waves of buddhists to fully understand the impact that meditation has on a person’s life.

For product managers, this book includes practical lessons to help you be more empathetic and rational at the office (and with your users) by tapping into your inner peace. It’s a great introduction to mindfulness if it’s something you’ve been wanting to learn more about.

Check it out on Goodreads.

7. The Hard Things About Hard Things: Building a Business When There Are No Easy Answers

By Ben Horowitz

This is a bookshelf staple for founders. Before becoming a VC, Ben Horowitz was a product manager and then a founder. The book is a real and honest look at the challenges of building a business.

I love his style because it’s relatable to any product person. The problems he discusses are not unique — they cross products, markets, customers of all kinds.

Check it out on Goodreads.

8. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t

By Simon Sinek

According to Simon Sinek (and I agree with him), figuring out why your company exists is important but it’s just as vital to get your people on board. This book walks through how to inspire trust and commitment within your team.

Your team will perform exponentially better when they fully understand why they’re doing what they’re doing.

Sineck also writes about the importance of safety. Safety = progress. And a great leader makes their team feel safe. When someone doesn’t have to worry about failing alone or the future of the company, they’ll be able to fully focus on their work.

This is a great read for PMs to learn tactics to get better results from the team they manage and the teams that they influence.

Check it out on Goodreads.

9. Zero to One: Notes on Startups, or How to Build the Future

By Peter Thiel and Blake Masters

Peter Thiel is a weird guy, but I love this book. It changed the way I think about product in terms of market fit, finding a niche and creating a monopoly in an untapped category.

Theil states that there are two types of innovation:

1. Horizontal progress: when you take something that exists and improve it — going from “1 to n”.
2. Vertical progress: when you create something brand new — going from “0 to 1”.

The most successful companies in the world (Google and Apple for example) won success by going from “0 to 1”. They were all once startups but grew to their size and power by introducing the world to something new.

This book is must-read for PMs thinking about making the transition to entrepreneur. You’ll learn how to find a niche and make an impact through disruption.

Check it out on Goodreads.

10. Delivering Happiness: A Path to Profits, Passion and Purpose

By Tony Hsieh

Tony Hsieh is someone I’ve always admired because of the importance he placed on team culture at Zappos. And there are many tactile lessons I took away from Delivering Happiness. This book is actually the reason why we introduced mandatory customer support training for all new employees at Roadmunk.

But as a product manager, this book really taught me how essential it is to fully understand a customer’s journey and experience. From top to bottom.

Every interaction — whether it’s an interaction with a customer success rep or how easy it is to find information on your website — impacts how they view your product and company.

It’s easy to get caught in a feature war with a competitor but that often comes at the cost o building delighters (inside and outside of the product).

Read this to learn how to build trust and loyalty to your brand.

Check it out on Goodreads.

11. The Five Dysfunctions of a Team: A Leadership Fable

By Patrick Lencioni

I really love taking the time to mentor other startup founders and product managers. And, over the years, I’ve noticed that there are a lot of similarities in the challenges and responsibilities faced by founders and PMs — specifically when it comes to communicating strategy and vision with the rest of the team.

Now, if an org isn’t aligned on what’s going on with the product in the short- and long-term, it’s going to be a huge problem when growth starts to kick in. Enter: dysfunction.

The Five Dysfunctions of a Team walks you through the root causes of team dysfunction — and there are five of of them:

• Absence of trust
• Fear of conflict
• Lack of commitment
• Avoidance of accountability
• Inattention to results

You’ll learn how to overcome all five — this is a book I recommend to many founders and PMs (both to combat dysfunction pre-emptively and reactively).

Check it out on Goodreads.

12. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration

By Ed Catmull and Amy Wallace

I chose this book to close off this list because it’s an inspiring, feel-good story. It’s the tale of how Pixar came to dominate the world of animation. And, hey, you’ll be surprised at how similar managing a product is to making a movie.

This book takes you inside of the meetings and brainstorming sessions at Pixar. And it’s an excellent book for PMs looking for ways to inspire creativity and originality within their team.

Catmull is super honest and candid about the techniques his team used to turn Pixar in to a widely beloved — and profitable — brand.

Check it out on Goodreads.

Happy reading 🙂

My 12 book recommendations for product managers was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

About 50% of all design firms sold in the last ten years were acquired in the last 24 months. And they weren’t bought by Amazon or Facebook or Google. They were bought by the banks and consulting firms — the BIG financial institutions. These organizations don’t have the most innovative reputations (after all, they’re referred to as “laggards”), so when even these companies are adopting design firms it says something drastic. It says: design should be a product priority.

Design is a specialized skill, and as a PM, it can be intimidating — especially if it’s not your natural inclination.

Having spent most of my career as a product manager, I’ve stated clearly — and to a lot of pushback — that design should always be a priority for product managers. Design is a specialized skill, and as a PM, it can be intimidating — especially if it’s not your natural inclination. (Plus, there’s usually a design team to deal with that stuff, right?) But that mentality is a missed opportunity; it’s equally important for PMs to keep design top-of-mind when making decisions.

Product design was one of our key differentiators when we founded Roadmunk. As I’ve previously written about, we didn’t necessarily have the data to back up that decision at the time. But look at these new statistics and tell me design isn’t rising in importance.

The laggards are waking up and savvy PMs are talking about how crucial design has become to the product development process. Now it’s time to integrate some concrete methods for bringing design more deeply into the PM process.

There are seven product design principles that I believe all product managers should follow. Blending my first-hand experience and observations, these are the essential design principles that I think every product manager must internalize and evangelize — especially if design is not your forté.

1. Tell users what to think

This first principle is an evolutionary design concept from engineer Steve Krug. It states that when designing, we should listen to our users’ needs to the point that we know and tell them what they should be thinking. Basically, you should understand your users’ workflow so much so that you can determine what they’re attempting to do. (Like an *actually* perceptive fortune teller!)

This example might help you visualize what I mean. Below, you’ll see flight search engine Kayak. It’s really well-designed, simple and easy to use. The problem, though: I’m not sure where exactly to focus.

While the UI is fantastic (the important things stand out, like the calls to actions and filters), I can’t confidently say the same for the user experience — which is just as critical as the UI. I see way too much competition between the various colors, equal priority given to all the filters, multiple lines of information in each section… It’s a lot.

Enter Google Flights. On an aesthetic level it doesn’t compare to the best websites you’ve ever seen — let alone Kayak — but they’ve done a really important thing: they’ve established the priority in which they want you to think about things.

You like nonstop flights? Bam! There they are at the top of the list.

Price is a big influencer for you? Awesome — here are the lower prices first.

Airlines and WiFi are deal breakers? Okay then, here’s that information upfront.

They’ve taken into account what they already know about their users and told them, “This is what we know you want.”

Google Flights is showing what matters. They’ve reduced the clutter by honing in on the key user needs and hiding/putting aside the other features. The filters are all still there; they’re just greyed out or lightened to improve the user experience. This to me is a great example of a company knowing their users and empathizing with them thoughtfully.

2. Minimize cognitive load

A basic but easily overlooked concept is that a user experience should be simple; your design should make the user think as little as possible. “That’s got too much cognitive load” is probably a phrase you’ve heard from almost every product designer ever. Okay, that might be an exaggeration, but the term cognitive load has become a keeper in the PM and design space. It’s a fancy way to say “cut the clutter.”

Let’s take the below example of an early version of the password program LastPass. I use this program all the time for its super-practical functionality, but looking at this early design, I’m overwhelmed for many reasons. For example:

• There is no focal point. Where the hell do I even start?
• Almost every button has the same degree of importance. Since when do edit, share and delete have the same weight as a user manual?!
• The icon colours don’t match at all. Like at all.

Compare this version to the site’s latest design and you’ll notice a huge improvement. They’ve designed for the user’s core action of searching for a program-specific password to change, edit or delete. So that means:

• Brand logos were expanded and put front and center
• A hover effect was added to each brand for the secondary options (edit, delete, etc.)

While the design may look significantly different, it was fueled by simple tweaks that drastically reduced the thinking on the user’s part and provided a cleaner emotional experience.

3. Three-click mentality

Simple exercise for you. Pick a website or app you love and see how many clicks it takes to get to a core action. Users don’t want to click on endless buttons to reach their destination; they want short and sweet. One core design principle PMs should internalize is that every single core action should be achievable within 3 clicks. Granted, not every application can do this, but this is a great opportunity to challenge yourself.

Let’s take Amazon. It’s a huge site. Imagine I bought something, I really love it, and now I want to tell the seller how I feel. How many clicks would it take to complete that task? Let’s see!

Step 1: ‘Your Account’ would be the natural first step to view past purchases. I hover over it — which we’ll consider half a click.

Step 2: Click on ‘Your Orders.’

Step 3: Scroll down the list and click on “Write a product review.”

Done. In 2.5 clicks I’ve reached my destination and can perform my core action. Despite being one of the biggest websites in the world, Amazon has taken into serious consideration how to streamline my user process.

Again, I understand this isn’t always possible, but I think the 3-click mentality can serve as a litmus test to see how friendly your application really is.

4. Reversible design

We all make mistakes — which is why product people designed the Undo button. Users can get pissedwhen they can’t undo an action (I’ve been there!). Yet so many of the products in market still don’t offer reversible options for certain actions.

Reversible design is more than simply clicking an undo button. Here are some examples of reversible designs from the tools I use every day:

• The little ‘x’ that lets me delete a filter on Intercom

• Deleting or removing files from Google Drive

• Moving a Trello card — then being able to drag it back to its original place

If your support center is frequently inundated by questions from users who have lost files or accidentally changed work they didn’t actually want to change, you’re probably going to want to give them a way to backtrack. Where would we be without Command+Z?

5. Use verbs with context

If your dialogue boxes are bogged down with words like Yes, No, Cancel and Save, your users might be a little muddled. This vague terminology only increases cognitive load. Half the time you’re not sure you’re taking the right action, prolonging a process that should have taken little thought and even less time.

Skilled designers have now narrowed down the options and provided context. Instead of a bevy of vague button choices, you get specific instructions: verbs/phrases like Cancel or Yes, delete this message. Simple. And on top of that, you get context telling you why these verbs are here (e.g. deleting the highlighted message). Already you’ve reduced ambiguity and cognitive load.

Sometimes it really comes down to something as easy as changing the text on the screen to significantly improve a user’s experience.

6. White space is your friend (a.k.a. Use white space to disrupt your competitors)

This dead-simple design principle can elevate your design from clunky to slick. When done well, it really eases the emotional experience for users. Designers tout this principle a lot, but there is still often a struggle to integrate the concept of white space.

Take a look at WordPress. Yes, everything you see on this screen is something you’ll need to use at some point in the blogging process. But when you’re actually writing (i.e. performing the software’s core activity), this UI is very disruptive. It comes off as heavy and messy. Only 25% of the real estate is allocated to the white space for writing.

The site has caught on to this criticism by providing a “Distraction-free writing mode” (the small button at the far right of the text editing toolbar) in their latest versions. Temporarily removing all the sidebars, this mode puts the writing space/white space as the central focus of the page.

Compare this to Medium, which has always been pretty much just white space. It provides a space to write your post, then add social widgets, type some tags and publish. Essentially they’ve made the process much easier for someone who might be jarred by WordPress or similar publishing platforms. And it hasn’t reduced functionality!

7. Design in MSP (Minimum Saleable Product)

So far, I’ve mentioned common design principles you’ll hear as a PM, but a less-talked-about principle is having your team design in MSP (minimum saleable product).

I stay away from language like MVP (minimum viable product) — unless it’s an infrastructure-related product — because to me that ignores user experience. It puts it as this far-off goal…a “nice-to-have” rather than a “must-have.”

Take the image below. The pyramid on the left shows that designing in MVP starts from the bottom (i.e. the pink) and works its way up the pyramid addressing emotional design as the last “need” of the product. Whereas on the right, you see that designing in MSP tackles all the “needs” in the pyramid — including emotional design — simultaneously from the start (i.e. why the pink component covers the entire height of the pyramid).

MVPs encourage teams to get something out there that is functional. It can break, but as long as the functionality and workflow are available, it’s solid. That, to me, is a “no.” What about the usability? Or emotional connection?

Think about any product you’ve ever encountered. When you first enter an application or product, you have an emotional reaction based on the design alone, which either does or does not spur you to click around and see if it’s usable. A product’s design is the first thing a user acknowledges before anything else; it’s the first impression.

A product’s design is the first thing a user acknowledges before anything else; it’s the first impression.

Yes, the product needs to be functional, but my sales team also needs to be able to sell to users. And not just to the early adopters and innovators: we need to sell this to the early majority. If these terms are unfamiliar, check out the Technology Adoption Lifecycle Model below. The model includes five stages of how a product gets adopted and the different customer segments within each stage. (More detail on those segments here!)

In his hugely popular 1991 book Crossing the Chasm, author Geoffrey Moore explained that for products to be successful, they must cross a chasm that exists between early adopters and the majority of the market.

Crossing the chasm is difficult, since the early majority is vastly different (i.e. pickier) than the first two groups, who are more willing to put up with bugs and reliability issues. The way we cross the chasm is through designing an MSP. How? Because pickier audiences in the early majority will overlook faults that may exist when you offer a product with superior design elements.

…the more you focus on packaging saleable features with compelling, user-friendly design, the more disruptive you can be to the market.

Take my team at Roadmunk, which focuses on UX and users’ emotional responses. We find that our users aren’t gathering their pitchforks and starting a manhunt when there’s an issue, because we’ve designed in MSP to ensure that our app is kinda really pretty (#shamelessselfpromotion). Don’t get me wrong, functionality is still key, but the more you focus on packaging saleable features with compelling, user-friendly design, the more disruptive you can be to the market. For example, our customizable template library is one such saleable functionality that’s hit the mark with our users largely due to its user-friendliness and design focus.

Final words: Let design be your secret weapon

Design has become more and more of a priority at product organizations, and it can be your secret weapon for standing out in a sea of competitors and changing the market. It doesn’t matter whether you’re working with your first prototype or the thousandth iteration of your product, your product’s design should always be on your mind.

Don’t just leave design in the hands of your design team; PMs should be living and breathing it, too. Take the time to put design at the forefront of your product strategy and see how your users become emotionally invested.

7 essential design principles for product managers was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.

Good things come in fives for Roadmunk. At the end of 2017, we celebrated our 5th anniversary. Our team had grown to 50 (and growing 🚀). Our customer base is over 1,500 (and growing). And that base is spread out across 5,000 cities worldwide.

I’ve experienced many delightful moments in the last five years as a co-founder and CEO — from meeting each new employee to escaping brutal Toronto winters together on two separate retreats in Costa Rica and Nicaragua.

I’ve also faced a lot of challenges and learned plenty of lessons along the way. So, I wanted to kick off our sixth year in business by sharing my story — an uncut version of this roller coaster ride. This is my experience as a founder, CEO and product manager at a growing startup — the hardest moments, happy surprises and most important lessons.

2013

What happened this year: This is the year that Tomas Benda and I founded Roadmunk. We worked out of my house for the first year — a prospect that Tomas didn’t mind because in his words, “Latif makes really, really good chicken.” I bbq’d a lot of chicken for us in that first year.

The hardest part: Laying startup idea #1 to rest

Our first year was tough because we realized — six months in — that our great idea had already been thought of by someone else.

Our initial plan was to build a requirements management platform for product managers. I spoke to ~80 PMs in our first six months to validate this idea. Only a handful of them were bought-in. And that’s because they had already adopted a requirements management platform into their workflow. Jama Software had built what we were envisioning — really well (I’m a big fan of them). There was no way we would have been able to catch up with them, so we decided the market wasn’t right for us.

We had to ditch months of work and start all over again.

While this realization was happening, I gave a presentation to ~30 PMs about the ecosystem of product management tools. It was an amalgamation of all the interviews I had done — plus my own experience as a PM. I had one slide about roadmapping. I spoke to how annoying it was to roadmap in Excel/PowerPoint, and I explained how one PM I interviewed built an internal tool just to create roadmaps. A guy to my left said, “I’d pay for that.”

Seed planted.

Creating and presenting roadmaps was a huge pain point for me as a product manager at Miovision. And it was a pain that came up in many of the requirements management interviews. Roadmapping software became a viable option to replace our now-dead requirements management idea. But we had limited funds left.

So, Tomas and I came up with a deadline. I would spend the next month validating the roadmapping idea and he would take on consulting work for a local startup to make some money. The pressure was on.

The most delightful: Validating idea #2 by signing customer #1

I took a different approach to validating our roadmapping idea. I built a landing page that described what our roadmapping tool would do and how it would benefit PMs. I ran an inexpensive SEO campaign that targeted keywords like “product roadmap” to get it in front of the right people.

Eighty people entered their email into that landing page because they wanted to learn more about our roadmapping platform. This wasn’t rock solid validation but it was enough to push us forward. And it gave us 80 new people to bounce ideas off.

And remember the “I’d pay for that” guy from my presentation? His name was Andre and he was a PM at P2P Communitech. I reached out to him to talk about his roadmapping woes. Together, we listed out what he would want from a roadmapping tool. I transformed those requirements into wireframes and designs for Roadmunk V1.

Andre signed on as our first pilot customer after seeing the wireframes and designs. That was all the validation we needed. And as a result, we were accepted into an incubator program.

The biggest lesson: Build a company that solves a problem you’ve personally experienced

I believe that the most successful founders are the ones that are building something that solves a problem they’re familiar with — a pain point they’ve experienced first-hand.

I spent over a year at Miovision struggling with roadmaps and aligning the executive team to my product strategy. Roadmunk solves a problem that caused a lot of stress for me as a PM. I knew the problem inside and out from the very beginning. And this shortened the validation process for our new idea.

My inside-out knowledge shaped how I spoke to PMs about our roadmapping idea. I already knew how Roadmunk would help them because their pain point was my pain point. For validation round two, I didn’t ask the same types of discovery questions that I did for requirements management — like, “What would your life be like with this tool?” or “On a scale of 1–10, how much easier would your life be with this software?” or “What would make you come back to this tool over and over again?”

I approached the validation interviews from the angle of, “Hey, I know this is a huge pain point for you and here’s why. How much is a solution worth to you?” (It also helped that the people we were talking to found our landing page on their own and gave us their contact info willingly.)

This second round of validation left us with something much more concrete. The people that signed up through our landing page agreed to be pilot customers and they were willing to pay us once the software was built.

Choosing to build a company around a problem you know will save you months (six, in my case) of chasing the wrong vision.

2014

What happened this year: We signed our very first customer before we even built the app — this led to us moving out of my house and into a coworking incubator space. And we built and shipped the first version of Roadmunk with the help of a couple engineering co-ops.

The hardest part: Shipping the product too soon

It took twelve months to build and ship Roadmunk to the public. I was in full product manager mode. My days were consumed by soliciting feedback from our pilot users, translating it into requirements, designing it, prioritizing it and then making sure quality was up to snuff once dev was done with it. Over and over and over again.

I knew the product wasn’t ready when it came time to ship. It wasn’t feature complete, but there was just enough in there to maybe start generating revenue. At the time, users could create a basic roadmap and move items around. The ability to collaborate wasn’t baked in yet, exporting was limited and the roadmap would get real precarious if you tried to add too many items.

Shipping a product that you’re not 100% confident in is a terrible place to be as a product manager. And, on top of that, I’m a type A personality. Perfectionism can be my kryptonite. At the time, I couldn’t reconcile having to ship an incomplete product.

But even though the product was missing a few key features, the ones we did have worked really well. PMs used the tool and engaged with it — this quelled my anxiety quite a bit.

Now I know that every product’s first few iterations are far from perfect — they’re often poorly designed, missing key features and super buggy. And a great PM is totally ok with this. The imperfection leaves plenty of room to make the product better based on user feedback. The sooner you ship, the sooner you can fix.

The most delightful: People started to pay us $$$

I wasn’t thrilled with the product that we shipped and I was anxious about how it would be perceived. But the landing page came through again. More people were finding it and signing up.

The delight in 2014 is pretty simple: We had 50 paying customers within 90 days.

I was extremely surprised and delighted when they started entering their credit card info into Roadmunk. Immediately.

I was dumbstruck. Tom was, too. We realized that we had something that was really special.

The biggest lesson: The Chasm is real

Quick refresher on the diagram below. It was created by Geoffrey Moore and published in his hugely influential book, Crossing the Chasm, about marketing technology products. Basically, the chasm outlines the different types of customers who will adopt your product at different stages of its life cycle.

It breaks down like this:

• Innovators: Tech enthusiasts who will always be the first to try new things.
• Early Adopters: Visionaries who are easily sold on new products. They are content with incremental improvements rather than perfection.
• Early Majority: Also known as “pragmatists.” This crucial section of the mainstream market requires a high level of quality and infrastructure to buy.
• Late Majority: Also known as “conservatives.” Their needs are similar to those of the Early Majority, but they’re more resistant to purchasing.
• Laggards: Late-to-the-party skeptics. This group rarely buys technology products.

In our first year of general availability, I learned to lean on the innovators/early adopters to use our product and provide feedback. Keep the early majority at bay for as long as you can. A year, at least. They will only want more features, workflows and uptime guarantees that you cannot give them. Trying to keep them happy will force you to make bad decisions early on that will be difficult to bounce back from.

We focused on building for 10% of our users in the first year — the innovators and early adopters. We set the expectation of “Hey, our product is not perfect. It can do this, but not this. The bugs might be frustrating, but we think you can help us make it better.” Sell the vision of the product and their contribution to making it happen.

They provided feedback that helped us build the right features at the right time — and we eventually got Roadmunk to a place that would make the early majority happy. And the percentage of customers we aimed to keep happy grew and grew as our product matured.

2015

What happened this year: Tom and I were still working out of the incubator co-working space. We began to meet with VCs to raise our seed round (we closed in November). And we started to grow our team by bringing on product, marketing and support hires.

The hardest part: Getting inside a VC’s head

Fundraising is never easy. Rejection sucks. And getting in front of the right VCs is tricky. But the hardest part for us was trying to figure out what the VCs were really thinking. And they didn’t answer our questions about their processes or what they wanted to see from us. We didn’t know how they made their decisions to invest or not.

I found this uncertainty particularly annoying (again, I’m — ahem — Type A), so we created our own rules of engagement for VCs, a structure with deadlines that they had to buy-in to.

My partner in fundraising is Jalil Asaria, our VP of Sales and Customer Success. First, we perfected our pitch. We had it down-pat after about 10–12 meetings. Next, we tackled the negotiation process. We created a timeline to get us from the pitch to the “Yes” in four weeks.

It wasn’t easy. It took us ~50 meetings to perfect that four week window — figuring out the right amount of meetings, when to take them to dinner, etc. We got a lot of “maybes” over those months and it was frustrating.

However, we managed to raise our seed round in November with an incredible Canadian VC fund called Golden Ventures.

The most delightful: We moved over half of our users from monthly to annual subscriptions

At the start of the year, 30% of our customers were paying upfront for an annual subscription. The 70% that were paying for a monthly subscription could easily cancel and move on at any point. This was scary given how much infrastructure work we had to do to improve and scale the product. We needed to buy ourselves some time. At this juncture, retention was more important than growth.

We ran an email campaign that incentivized users with a 30% discount if they upgraded from monthly to annual subscriptions. By the end of that quarter, we doubled the amount of customers paying us to use Roadmunk for the year.

This is delightful on many fronts for a founder. It gave us stronger negotiation leverage with our investors. We were able to hire more and grow faster. And, most importantly, I didn’t have to toss and turn at night worrying about payroll.

The biggest lesson: Teach your customer support team how to sell

Do not hire any sales reps this early on in your startup — before market-fit is solid or if ARR is less than $1M. Instead, teach your customer support team how to close transactional deals.

Jalil, our VP of Sales and Customer Success, decided to take this approach for a few different reasons:

1.) Good sales reps are expensive and they are sometimes one-dimensional. Your Customer Success team can often do a lot more — they can run demos, train users and answer all product-related questions throughout the user’s entire lifetime as a customer. This saves money on headcount AND provides a better experience for users because they don’t have to be bounced around from sales to support rep.

2.) A big sales team influences overall culture in a big way. They demand a lot from marketing and other teams within the organization. A sales-driven culture = pressure. A support team that can sell in a more organic way relieves a lot of that high-wire stress.

3.) It’s easier to win land-and-expand deals. Happy, well-trained users are the biggest advocates and sellers of our software. They’ll show their colleagues how to use the tool and explain why they should — and the support team plays a, well, supportive role in converting them to paid users.

2016

What happened this year: We moved into our first legit Toronto office space at the end of the year. And we got to know some awesome product managers from really cool companies because they signed up to use Roadmunk.

The hardest part: I made some product decisions that no one agreed with

We faced a lot of difficult product decisions in our second year of general availability. Some decisions led to the path of differentiation in the market. Others would have turned Roadmunk into a carbon copy of the competition (something I really, really wanted to avoid).

I spent a lot of 2016 in the middle of tough conversations with the team. I was constantly going against the majority. I wanted to invest more time in improving the parts of our product that delighted our users. Others wanted to reinvent entirely different parts of Roadmunk.

Our product manager at the time insisted on moving our most-requested feature to the top of the queue without fully understanding the impact it would have on our infrastructure. I had to intervene and push the feature out four to six months in order for our dev team to handle it.

From a co-founder perspective, situations like these are stressful. I had to prioritize employee happiness over end-user happiness — and being forced to choose between the two feels like being caught between a rock and a hard place.

I was basing my decisions on my own instincts — but that’s not the type of reasoning that sways pragmatic product people and developers to change their minds. I had to dig in and always backup my assumptions with market research and qualitative information (which takes up a lot of time).

The most delightful: Good vibes only in Costa Rica

2016 was a year of perpetual growth. The special kernel of an idea we landed on in 2013 had grown into a business that was growing 30–40% month-over-month.

Yeah, we had challenges around product prioritization — but (and please excuse how trite this is) the positive vibes felt around the office were potent.

And we shipped the whole company to Costa Rica for a month. This retreat solidified our mandate to be a culture-first company. For us, culture = balance. Career and fun. Hard work and freedom. Business and friendship.

You can read more about why I took the whole team to Costa Rica here.But the gist of it is: A team that knows each other grows together. And we’re still reaping the benefits of the core team being so in sync with each other after living and working together abroad for a month.

Plus: In Costa Rica, we surpassed several sales milestones and it was the strongest month we’d had up to that point.

The biggest lesson: Founders — don’t give up control of your product too soon

Up until early in 2017, I oversaw a lot of the decisions made by the product team. I truly believe that handing over your product to another PM is a mistake when done too soon.

I say this even though being so involved with product for so long took me away from working closely with other teams, like customer success or marketing. Being a product founder / CEO is a fine line to walk at times, which resulted in unpopular decisions and moments of friction.

There are plenty of small hiccups that have made this lesson evident for me.

For example, we were working on a revamp of our field management functionality. I decided to be completely hands-off on this. One of our very talented designers led the project without much oversight from the PM (I wasn’t aware of this particular puzzle piece). The release of the revamp kept getting pushed out further and further — and CS was getting anxious. Turns out, communication between the PM and engineering was too infrequent. I had to step in and make some decisive decisions to help ship it faster.

This mishap cost serious dev time.

Until recently, I I felt like I had to be tied to all of our big product decisions.

I wanted every single one of our PMs to think exactly like me because Roadmunk was built based on a pain point that I’m all too familiar with — and I think my instincts are often right when it comes to what’s most critical to our customers. And I’ve spent years talking to our customers so I know them really, really well. I still often find myself speaking on behalf of our customers because of this.

What I’m really saying here is that it all comes down to trust. Take your time hiring a product manager that you trust — someone that you’re comfortable handing your baby over to.

And, once you do hand off product, stay close to the team to keep a pulse on what’s going on so you catch any issues quickly.

2017

The year summarized: We doubled our headcount from about ~25 to ~50 employees. And we moved again — this time into a beautiful offices that we can stay in for years. Signup goals were surpassed more than once. And we went on a second retreat.

The hardest part: We realized our tech was not set up to scale

I’ve established that Roadmunk has grown pretty steadily month-over-month and it’s been an incredible journey… but we weren’t super ready to grow as much as we did in such a short amount of time.

App performance took a hit.

We didn’t realize it was a problem until it was a problem (and hey, this is a problem that many tech companies experience — even Instagram).

Because I was still so entrenched in product management, I was spending so much time talking to customers and trying to make them happy that I neglected to make sure that engineering had a plan in place to scale as needed. And, obviously, performance ended up being a huge customer pain point.

While he have acted on the scaling issue, the hardest part was recognizing that we should have caught it a lot sooner. We should have built better communication bridges between customers, product and engineering.

The most delightful: More good vibes in Nicaragua

The Costa Rica retreat was such a success in 2016 that we took our now much bigger team to Nicaragua for a magical remote-work retreat.

This retreat required an extensive amount of planning given the number of attendees. Logistically, Roadmunk pays for food and accommodation while employees cover flights and local activities. We had workstations, decent wifi and a beautiful view of the beach.

If you’re waffling on whether a trip like this is a good idea for your team, it is — believe me.

We’ve seen ROI from our retreats. The fact that we go on these trips really helps in attracting world-class talent. We’ve produced a world-class team since then because candidates can see that we actually live our core values — instead of just sticking them up on a wall. An A+ team makes investors more confident in our future so they’re more open to fork over more cash (We got a term sheet while we were abroad).

And the month we were in Nicaragua, we had our best sales month up until that point.

The biggest lesson: Hiring people that know more than you will reduce stress levels by a lot

2017 was the year I learned the most. It was full of lessons (mostly because I’ve never managed so many people before) but the one that stands out is the value of hiring experienced team leaders.

Everytime I hired a VP, they had this amazing ability to learn the business at lightning speed, build relationships with key members, surface existing problems and solve them in short order. They were also able to quickly identify areas of growth.

Hiring VPs to lead each department has relieved a lot of stress for me as a CEO. Yeah, I can come up with ideas and start to execute them with different teams, but I don’t have the time to make sure that they’re implemented to scale. VPs can. They’ve been through the ringer to achieve their seniority. Very little phases them. Their lack of stress makes me less stressed.

For example, Andrew Archer, our VP of Growth and Strategy, was brought on in 2017. He started and finished an important project (one that I could not find the time for even though I really wanted to) right away. Within weeks of starting, he led a strategy session to reevaluate and rejig our company vision, strategic objectives and core values.

Thanks to his speedy work to get the whole team aligned, we were all able to start 2018 on the same page.

And I think it’s going to be a great year. 🙂

So, that’s how five years as Roadmunk’s founder/CEO shakes out. And I’m looking forward to seeing what the next five bring. If you have any questions about this crazy business of building startups, shoot me a message on LinkedIn.

Roadmunk turns 5: The biggest challenges, surprising delights + hard knock lessons was originally published in Roadmunk on Medium, where people are continuing the conversation by highlighting and responding to this story.