brandon reti

Breather and Ottawa’s Startup Scene

Two weeks ago I was invited to speak at Startup Grind Ottawa. I’ve learnt quite a bit about Ottawa over the past few months. Up until February of this year I was ignorantly unaware of the awesome talent that lies around 200 KM outside of Montreal. I met the guys over at Tattoo Hero and fell in love with their product, we clicked, and now I advise them. Brandon from TH intro’d me to Jon Milne from Invest Ottawa who asked me to speak at Accelerate OTT. At Accelerate I met more people in the vibrant startup community. Don’t take it the wrong way, I’m not name dropping, rather I’m blown away at how nice and intelligent all of the people I’ve met are.  A city generally known for parliament and government jobs has planted a new flag. Ottawa clearly has a killer tech scene with companies like Shopify, TattooHero and GymTrack.

That being said, our team at Breather knew we wanted to not only support the startup community in Ottawa, but be a part of it! We’ve just launched two Breather locations and a third is quickly on its way. You can check out our ByWard Market location on George Street and Metcalfe on Metcalfe Street.

ByWard Market

Metcalfe

If you’re interested, here’s my talk with Franco Varriano from Startup Grind Ottawa. I spoke about Breather, best practices for building product, the sharing economy and how to turn your data into revenue.

3 Reasons Why Your Product Is Bloated.

Many of the product managers I’ve met are restless characters who are always busy iterating, building product and keeping the team on track. This is the way it’s supposed to be done, small incremental change, pushing toward a goal of optimizing your funnel and driving more revenue. There’s a bit of a dark side though, and it often comes in the form of feature bloat. I’ve spoken about this issue quite a bit, and the purpose of this post is to give a few simple tips on the warning signs that you’re on the path to bloat. Feature bloat usually ends up rearing it’s ugly head because of ego, and most commonly can fall into the following three categories.

Politics: This is one of the areas management needs to be fully on top of and do everything to prevent. Office politics are not only distracting, but also cause emotional distress for employees.

Office politics are a slow debilitating cancer that can destroy a product.

A PM, CEO, CTO or CMO can request a feature just for the sake of having their finger prints on the product. “I made an impact!” Good for you, you just took a huge crap on the product, want a medal? I have personally fallen victim to this while working in the adult space. Upper management thought they had a good idea, they wanted full community integration into one of the sites. This took countless hours of planning, API and design work. In the end, only 1% of the user base used it! We could have been working on areas of the product that would have made the experience better for a larger subset of users and drove more revenue. Instead, we spent 6 months and countless man hours to implement something that was “cool”, but drove zero revenue, and had little product impact. Lesson learned.

Lack of testing:

Why the hell would you spend hours developing a complicated feature when it could be tested in a simplified form?

I’ve said it time and time again, don’t bake something into your product unless you are near certain it will work. You’ll never be 100% sure, but trying to prove your hypothesis with a few tests is a great way to prove your point. There’s no shame in testing, there’s only insight to be gained. We are huge proponents of this at Breather.

There is nothing worse than deploying a new feature and then having to remove it.

It’s completely unprofessional, disrupts user experience and can cause customers to quickly lose faith in your product. Here’s an example:

Suppose you want to know whether or not a new feature would be useful to your user base, how do you find out? The answer is quite simple, ASK THEM! You probably have a long email list and some data on how active those users are. Take your most active, least active and average users and email them. Use a service like Intercom to do so. Put together several questions on the feature you’re planning on building and ask whether or not it will help them. Also, offer them some form of reward for their opinion. In our case, we offered Amazon gift cards. Is this perfect? No, but it will give you some valuable insight into how your users think, and it’s low effort.

Boredom: This one is usually management’s fault as well. If your employees are bored and un-motivated, they won’t put the effort into testing, and you’ll end up with people doing useless busy work that’s bloating your product.

Make sure you are engaging your team and empowering them to make good decisions. If you don’t, your product will suffer, morale goes down, and it’s a self perpetuating cycle that’s hard to break.

Management needs to constantly get their hands dirty and be present!

There’s no silver bullet to prevent politics, lack of testing and boredom, but I have outlined some ways that management and employees can see the signs and hopefully curb the damage. At the end of the day, if you don’t fix it, the company, and you will suffer. Plain and Simple.

3 reasons why your PM’s should learn to code

Over the past few years there’s been a movement surrounding programming education. There are tons of startups that have emerged in the “learn how to code” space. I am generally an optimist, but I‘ve taken quite a cynical approach to this. Many learn to code sites have come out and proclaimed “everyone should learn how to code.” Think about that, should everyone learn how to code?

Should everyone know how to make their own clothes? Should everyone know how to hunt? Of course not!

The proper answer is, everyone should be afforded the opportunity to an education, not just blindly told to code. One of my few passions is technology, and how technology becomes the fabric that ties us together. This is one of the reasons why I work at a startup.

Just over a year ago I joined Breather. I had come off a very successful 4 year stint in the adult industry. I managed around 20-25 programmers, 5 QA’s, a bunch of analyst and a few PM’s, but I couldn’t code. Was that such an issue? At the time I didn’t think so. I was able to get engineers to work together, I had their respect, I could describe the features I wanted built, I was able to forecast timelines properly, but, I was never able to fully understand how engineers built software.

Before I dive into the nitty gritty, understand that finishing a course like Codecademy does not make you a programmer. Over the past year I’ve learned the basics of the following languages: HTML, CSS, Java Script, jQuery, Ruby, PHP and currently, Objective C. Most of the programming courses out there will give you a working knowledge of these languages, by no means will you be an expert. Every now and again I get a tad too confident in my programming knowledge and I say something stupid, thinking I understand a topic. Fortunately, our engineering team is really cool, and rather than make me feel like an idiot, they help me understand what’s going on. I’m better at building product because of it. So, why bother to learn to code?

Communication with Developers:

I hear it far too often, PM’s say something to the effect, “just get it done,” without knowing what “it” is. As a PM you’re constantly working with engineers, I’m not saying it’s impossible to get their respect without learning to program, as pointed out by the example directly above, but you’ll be at an advantage. You can effectively add to the development conversation and speak their language. You can follow up throughout the dev process and understand what’s done, and what’s left to be done. Not only that, but if your CEO asks you “why isn’t this done yet?” You can offer a more confident response and not just blame it on engineering.

Quality and Iteration:

Shipping product is a major part of a PM’s job. Wether the product is consumer or business facing, you need to be able to iterate and continuously move the product forward. It is not an engineers job to tell you what feature should be next, it’s yours. If you have a working knowledge of programming, you’ll understand what steps are necessary to build the feature properly. By having all the facts you can make decisions on what features should go out first. Not only that, you can aid in the QA process and ensure the product is functioning the way it was intended to.

Fixing the Small Stuff:

Working in a startup is all about being agile and working outside of your comfort zone. I’ve been working in technology for 1/3rd of my life, and by no means am I even close to knowing everything that’s out there. Everyday at Breather I try to learn something new. Your programmers are busy and might not have time to make a small change to your website, an email newsletter or FAQ’s. By learning the basics of programming, you can aid in these day to day tasks. I have been able to make changes a few times, it’s generally a last resort as I am always worried about breaking something, but the important thing is I’m getting better every day.

The gist of it is, you can be a good PM without a working knowledge of programming, but you can be a killer PM, and have an advantage if you take the time to learn.

Purpose, accountability and transparency, the key to a data driven culture

Making a sale is great, right? Of course it is! There’s nothing more exhilarating than seeing a product you helped build, come to life. Many businesses, particularly startups fail because they fail to generate sales, don’t look at how they made a sale, or worse, their focus is solely sales, without looking at cost of acquisition. Fortunately there are ways to mitigate risk and to ensure that your entire team is focused on the key metrics that will help you succeed. As an advisor and someone who has helped build small and large businesses, I have come to learn that if you only focus on the last part of the puzzle, you’ll likely fail.

That being said, how do you create a culture that’s data driven and focused on the right KPI’s? There are plenty of awesome articles out there on this topic, namely Pirate Metrics by Dave McClure. The point of this post is to discuss culture rather than the actual application of these metrics, I’ll save application for another time. Here are a few tips to ensure your team is on-board.

Purpose: Not all data is created equally. You’ll lose your mind trying to track absolutely everything your users are doing. You’ll likely read too much into things and get distracted. Focus on the key items. When I talk with startups about tracking user behavior, I usually force them to focus on the funnel before anything else. Track the funnel that relates to the one important metric your company is concerned about, and optimize that before you do anything else.

Accountability: You’ve got people working for you, but how can someone be truly accountable if you don’t have concrete evidence that something they did works? Each person that works for you needs to own some portion of the metrics. A prime example is email marketing. Your marketer should be accountable to open rates, click rates, shares. Your job as a business owner, CEO or manager is to set goals and ensure that decisions are being made based on data.

Transparency: This is by far the most important of all the points. If you are cagey about your data with team members, they won’t trust you. At the rate startups fail, you can’t afford to not be transparent with your metrics. I’m not saying that all data should be shared, but data surrounding your KPI’s should be. If everyone in your company is focused on a few key metrics and knows how their role can bring the numbers up, you’ll have a much more engaged staff. This is easy to do.

At Breather we have a company dashboard that has our KPI’s. This dashboard is always up and running on a screen in our office. You can’t avoid it! If you walk to the kitchen, bathroom or to a meeting, it’s there, staring you right in the face.

It’s one of the tools we use in decision making and it’s always top of mind. There’s one caveat though, this only works if step 2, accountability is adhered to. There needs to be consequence and reward for actions. If the team collectively hits the numbers, we grab drinks on Thursday, if we don’t, we discuss why and take steps to rectify.

There’s one very important thing to remember throughout all of this. Once you start implementing a data driven culture with purpose, accountability and transparency; you need to be able to prevent decision paralysis. This is when you refuse to make changes due to the fact that you don’t have enough data or you’re scared that the change you’ll make will hurt the numbers, and you’ll look bad. You need to keep you’re team thinking creatively and know that even though they’re accountable to the numbers, they still need to stay creative, take risks and try new things.

At Breather we always say, ask for forgiveness, not permission.

Porn, Bomb Threats and Startups

May 24th, 2013 started off like any other day. I got up, walked Milah, hit the gym, said goodbye to Sarah and drove to work. The afternoon rolled around and someone called in a bomb threat at Manwin. My programmers and I had just pushed a new feature that would impact a lot of people, and it needed live testing. I was totally stressed out and waiting in the parking lot for 45 minutes to be let back in the office. I don’t think they ever figured out who called in the bomb threat, but it was probably just some dude who really didn’t like the porn industry…go figure. What’s important here is the text message I got from my buddy Julien Smith during the event.

Julien and I met through a mutual friend, Greg Isenberg, a few years back. Julien was really interested in my adult-industry background, and the large volume of users I dealt with on a daily basis. Now, during this parking lot episode, in usual Julien fashion, the text I got was vague: “I wanna ask you something” or “ I wanna know if what you can do for Manwin, you can do for me?” Little did I know that this text message changed the course of my career and how I envisioned success.

I was 28 with an awesome job. I traveled the world, made great money, had over 40 people working for me and impacted the lives of 20 million people a day running Pornhub and Youporn mobile. I accomplished more before 30 than many people get to do in their entire career. Did I really need more? The answer was “hell yes,” but not for the reasons you might think. Working at one of the largest adult companies in the world had its drawbacks. It was one of the most treacherous political landscapes I had ever seen. I was tired of arguing and spending most of my day fighting battles. I truly enjoyed my team and the challenge but the fun was no longer there.

I did what I had to do. I helped build a department from nothing and execute a strategy that made Manwin millions of dollars per month.

When Julien told me about the idea for Breather I remember saying to him “this is crazy, it’s either going to work really well or implode, there won’t be a middle ground here.” I had been working with big brands like the NFL, NHL and Family Guy before I worked at Manwin; and at Manwin I was selling sex. These were somewhat established companies with some infrastructure. I had never built anything from scratch before, and considered myself a risk-averse person, a little too nervous to start my own company.

Breather was a crazy idea with some funding and a website. This was my way to prove to myself that I could help build something from the idea phase and shed my risk-averse nature.

Fortunately my instincts about taking the gig were right. The past year has been pure insanity. In under 9 months we’ve built a full iOS and Android/web booking interface, we have over 15 locations in 2 countries, 3 cities and more than 10 employees.

The bottom line is if you like routine, job security, a 9-5 schedule and an expense account, a startup isn’t for you and that’s nothing to be ashamed of.

If you’re comfortable with a 24 hour neurotic feeling of not knowing where you’ll be in 3-6 months from now, and a schedule where you’re always on…then jump in head first. That may sound genuinely terrible, and it can be, unless the idea works. The feeling of building something from the ground up and having people tell you how your product “helps them” and how they “love it” is one of the most rewarding feelings I have ever felt.

Why you’re probably wrong about your MVP

Does the title sounds hyperbolic? Maybe, but think about it. When was the last time something turned out exactly the way you wanted? You’ve got best laid plans but something comes along and gives your plan a little shove and you’re on another path, whether that path is good or bad is up to you to decide. Last week I posted about my experience at AccelerateOTT, here’s the follow up video where I discuss how all the different roles in my career that have helped me become better at building product. Whether it was my time at Airborne, my time building Pornhub and Youporn mobile (don’t expect a link!) Or my current role at Breather. All these experiences helped me hone my product development style.

Where you start isn’t where you’re going to end, and as someone who’s been building product day in and out I’ve come to realize that products, like people, need change and evolution. Users can’t handle products that are bloated with a bunch of different and unnecessary features…but why? The answer is actually simple: feeling overwhelmed. You have a few seconds to sell your product to a user. They’ll download your app and if your signup process is difficult, if your UI isn’t intuitive, you will lose that user – plain and simple. So, how should your product evolve? What features are necessary? That all depends on what you’re building, but I’ll share the method we employ at Breather.

Before you start building, figure out the one metric that’s important to your business and every feature you bake into your product should be focused on growing that metric.

 

Now, when you and your team are planning, before you say “oh we need this feature!” Think about it, do you really? Do you need another image filter, a fancy carousel or a notification for every event in your app? Probably not. Look at “Yo” and “Secret.” You can’t do too much in these apps. You can send a “Yo” or share a “Secret” with a cool background image. That’s it. It’s easy to understand, dumbed down and straight to the point.

At Breather our goal is to get people into our spaces. Our ethos while building product is:

How do we reduce friction and make it easier to get people into our spaces?

Every feature we develop and build into the product is based on this! It comes up all the time and is the lens for making decisions. There are a million different ways to think about this, but the KISS Principle is my fav.

That’s it! Until next time – keep it simple, stupid!