“Agile…lean startup…fail early…fail fast…fail cheap…”. These terms are tossed around but what the heck do they mean?
More specifically…what do they mean when you’re building a product and running a business? Today I’m speaking with a panel of product experts who will explain these terms and how they apply to every business. If you’re about to build a product and wonder where to begin, you should listen to this episode. If you want to hire the best talent for your technical team, you should listen to this episode. If you want to become a more successful manager in general, you should listen to this episode. Learn from the experts who do it every. single. day. I’m speaking with Tami Reiss, CEO of Cyrus Innovations, who created the #JustNotSorry Gmail plug-in that’s been making waves. Also on the panel are Nikki Kuritsky, formerly head of product for Christie’s, now VP of Product at Shutterstock, and Allessandra McGinnis a product manager at Autodesk. They will share their hard-earned “trade secrets” for how to design a great product roadmap, build awesome product and why they believe in putting the “H” back into managing teams and creating team culture. For those of you who want to know what the “H” stands for, you should listen to this episode!
Agile vs. Lean vs. Lean Agile by Tami Reiss
5 Traits of a Good Product Manager by Benjamin Hawkyard, Medium
Don’t create a sense of urgency, foster a sense of purpose. by Kimber Lockhart, Medium
What Product VPs At High-Growth Startups Have In Common by Mike Belito, Medium
Your First 100 Days by Niamh O’Keeffe, iBooks
Disrupt Yourself by Whitney Johnson, iBooks
Guest bios & transcripts are available on www.broadmic.com.
Allessandra is currently a product manager at Autodesk on their Spark 3D Printing platform. She focuses on making it easier to automatically customize products to be manufactured by a variety of 3D printers. Previously, Allessandra was a product manager at Shapeways, the largest 3D printing service and marketplace, where she was responsible for envisioning and executing the product roadmap for the easy customization and visualization of 3D printed products. Before moving to New York City, she was at Microsoft building Bing’s developer platform and integrating Bing’s nascent technologies such as natural voice recognition into Xbox and other consumer products. Originally a Chicago native, she graduated from the University of Michigan magna cum laude with a degree in materials science and engineering.
Nikki Kuritsky is a senior product leader with over 10 years of experience developing successful, consumer-centric products and bringing them to market with close attention to schedule, quality and user experience. She is passionate about creating products that solve customer pain points and delight the user in unexpected ways.
In her current role as VP of Product at Shutterstock, Nikki is responsible for defining strategy and leading the product team to drive innovations that enable a market place for creative business professionals to find the highest quality content. Previously, Nikki was the VP of Product Development at Christie's auction house and held various positions in the entertainment and publishing industries, overseeing product teams at Viacom and Rodale. Nikki is a graduate of the University of Michigan and the Columbia University Publishing Course. In her down time, Nikki is an active runner, foodie and world traveler. She lives in Brooklyn with her partner and son.
Tami leads the Cyrus team to deliver great results for our clients. She focuses on ensuring that Cyrus is a great development partner, guiding clients through tough times and helping them grow. She is an experienced product person who has worked with dozens of companies of all sizes to bring their products and services to market. Over the past 10 years, Tami has worked with teams to develop technology solutions on platforms ranging from mainframe systems to modern microservice architectures and iOS. She is a public advocate for Agile development, Lean strategies, and cross team collaboration to accomplish business goals. Prior to joining Cyrus, Tami was a Sr. Product Manager at Pivotal Labs where she consulted with companies on employing best practices to turn good ideas into great products. Tami introduced the Female Founder initiative to Cyrus. She provides pro-bono product strategy guidance to help women led and community profit organizations. In her free time she chairs a charity bike ride, volunteers for different women in tech organizations, and is trying to visit 50 countries and all 50 states by the time she’s 40.
Tami: In order for you to know you're heading in the right direction, someone either needs to be able to give you their time, their money, or their social capital.
Kelly: I'm Kelly Hoey, host of BroadMic. I speak with the most accomplished entrepreneurs, investors, and thought leaders about the issues that matter in building a business. You will get the inspiration as well as the picks and shovels you need to become a better entrepreneur. Be inspired. Take action. Think Broad.
Agile. Lean startup. Fail early. Fail fast. Fail cheap. These terms are tossed around, but what the heck do they mean? More specifically, what do they mean when you're building a product and running a business? Today, I'm speaking with panel of product experts who will explain these terms and how they apply to every business. If you're about to build a product and wonder where to begin, you should listen to this episode. If you want to hire the best talent for your technical team, you should listen to this episode. If you want to become a more successful manager in general, you should listen to this episode. Learn from the experts who do it every single day.
I'm speaking with Tami Reiss, CEO of Cyrus Innovations. Tami also created the Just Not Sorry! Gmail plugin that's been making waves. Also on the panel we have Nikki Kuritsky, formerly Head of Product for Christie's, now Product Manager at Shutterstock, and Allessandra McGinnis, a Product Manager at Autodesk. They will share their hard-earned trade secrets for how to build product, and how they are putting the H back into managing teams and creating team culture. For those of you who want to know what the H stands for, keep listening.
So help us develop a working understanding of the different product roles. We hear titles like Product Manager, Product Marketing Manager, Product Strategy Manager, there's probably a Gluten-free Manager I've forgotten, but let's understand, "What are these product roles?" And Nikki, you've held a number. I want to look at you. How should people understand these product manager roles generally?
Nikki: So in many large organizations, the product team is really solely responsible for defending the product. Product marketing comes in as more of part of the marketing group, where you're basically taking a product that's already been defined and you're figuring out how to market it. In many large organizations also, one of the ways that the team is really broken down is that the person who's kind of the most senior is helping to define what the product strategy will be, and the product managers are really thinking about how you're actually going to carry out that strategy. So an analogy that I could use is that if the product strategy is just, let's say, "We're going to drive west."
The product managers are helping to define the route. Are we going to go on 80 all the way? Are we going to go through Pennsylvania and Chicago and Minnesota then end up in San Francisco? Are we going to go south and end up west? Kind of the futures that you're coming out with are those stopping blocks along the way. One of the roles of, I would say, the product team lead is really helping to figure out kind of what the best route might be. Assessing kind of, "What are the things along the way that are really important to you? Is it that you get there really fast? Is it that you get there really cheaply? Is it that you get there with your car in the best condition possible?" So kind of, it's out weighing like quality versus speed versus cost.
That's really what the product team lead is doing to kind of oversee the strategy and make sure all those product managers are getting to one place safely, and they're getting there in the best route possible. It's a lot of kind of juggling and coordinating, and the product team is generally wearing many hats. As a product manager, you're also a project manager. You're thinking out, "How does the thing that I'm putting together affect other things down the line?" You're really considerate about dates. You're working with the development team, the design team to make sure that your vision of what the product is going to look like is actually being executed in the best way possible, both in terms of how the product is working and also how the product looks.
Kelly: Awesome. I'm looking, and I've got much better understanding now, so thank you. I'm looking at you, Allessandra, because you have...in a role you had at Microsoft, you moved from product marketing to product management. What was that transition? What was your thinking on why you wanted to do that?
Allessandra: Yeah, absolutely. So at Microsoft, I had about a foot, I like to say, in each world. I had one foot in product management and one foot in product marketing. Product management is really about being responsible for the value proposition of the product that you're building and really understanding who the customer is. With product marketing, you're not necessarily responsible for that value proposition, but for how to tell that story to your target audience and really make them fall in love with your product for the reasons that that product was built. And what I've found is that I really felt like I had a seat at the table when it came to being in product management. I could really ensure that the product was going to have value to that end customer. And with product marketing, I would often be pulled in a couple of weeks before launch, possibly a couple of months.
Sometimes, you get a product that is fantastic and it's really easy to pull that story out and tell that story. But other times, you are faced with trying to market and really come up with the core value proposition for a product that maybe hadn't been thought through all the way and possibly didn't have a target audience. That makes your job incredibly difficult as a product marketing manager. So for me, I ultimately decided to leave Microsoft and join Shapeways to do a full-time product management role because I really wanted to, A, never put a product marketing manager in the position that I was put in very seldomly, but enough that it was painful at Microsoft. But also really always have that seat at the table to make sure that any product that I was a part of or responsible for had a really strong value proposition. So for me, those were kind of the differences between the two roles. Both incredibly difficult, but for very different reasons.
Kelly: I was saying what a benefit early on in your career to have those kind of two roles almost at the same time and that incredible self-awareness about what it is that you want to do and what kind of rocks your world from a career point of view, versus, "Oh, gee. I wonder what product marketers do. Wouldn't it be interesting to try to actually do them both at the same time?" Tami, I want to ask you. Are there different skill sets or backgrounds for both? If you're looking at hiring someone for strategy versus product management versus product marketing, what do you want to see and what are the skill sets you're expecting each of them to have?
Tami: So what I like to say about product management is that the two most important skills that you ever have are prioritization and communication. So communication is bi-directional. So that may be that you're helping out the marketing team and figuring out how to communicate to your potential users. It may be that you're talking to internal team members about, as Nikki said, the path that you're moving forward. So how do you say, "Chicago is our next step along the way" to all the people who are driving the car? When it comes to prioritization, it's not only choosing the route, but it's saying, "All right. We made it to Chicago. Should we go left or right now, based on what we've learned in the first part of our journey?"
So when I look for a product manager, those are the two things I really want to see. Can you make a hard decision? Can you prioritize one thing over the other? Can you weigh in the business goals to understand what path should be taken? And then, can you communicate that with others? So is that communicating with the product marketing manager, who is then going to communicate with users? Is that communicating with your team? There's different levels depending on the organization, but those two things are really where it all comes in to be key. Whereas a product marketing manager has to be so much stronger when it comes to communication.
So skills I look for in a product marketing manager is somebody who can write copy. Somebody who can be succinct. Somebody who can summarize. Somebody who knows how to use action words, and not drone on and on and on about all the different features, but really distill the features of a really large product into just the really key parts that are going to resonate with a potential buyer.
Kelly: There we go. Clear. Absolutely clear. Thank you. I was going to say, "Am I likely to find all of those roles in one company, or does it depend on the size of the company of whether you've got one, the other, or both?"
Tami: It's 100% dependent on the size of the company. There are very few companies that, even at a large scale, work in small pods of cross-collaborative teams. But very often what will happen is that as a company grows, like in any other respect, there'll be layers of management. Middle management starts showing up. So you might have a more product strategy person on a higher level. And they're doing market research, and they're talking to those teams, and then they're working to then tell the product team the data they've collected and saying, "Based on our strategic vision for the company, this is where our product needs to go." Then the product manager's in charge of working out the individual features, like Nikki described. But in a small company, a product manager is often doing all of the things, including product marketing, including the product research. So as a product manager at a small company, you have to be ready to really roll up your sleeves, get a little bit uncomfortable, and try something new.
Kelly: And work on that coppity [SP]. Nikki, you're nodding your head on this. Has this been your experience from being in publishing?
Nikki: Oh, totally. Yeah, I think especially working in small teams, you're wearing many hats. For many organizations, project management actually comes second to product management. So it's often that the product manager is also acting as a project manager, so organization is really key. When I look for product managers, I look for people who could actually just function on their own without a project team, because I know that for any reason they should really be in control of their projects. They should be thinking out fully everything from start to finish, from conceptualization all the way through launch how long they're going to need, and how they're going to communicate to various teams without the help of a project manager there.
Kelly: Well all of this, hearing organization, prioritization, the direction you're going, all I can think about is Eric Ries's Lean Startup approach. Which of course has been a major phenomenon over the last four years impacting not just the startup community, but big companies and how we are approaching creating product and leading projects. Let's talk about some of the key features of that, you know, MVP, build, iterate, test, and my favorite, failing fast. But let's start with some definitions in case people don't know exactly what they are, and how you all as product people think about MVP. I'm going to look right at you, Allessandra. MVP. What are we talking about?
Yeah, absolutely. So MVP, or some people call it the minimal viable experience I know is something that I've definitely heard in my team, is really trying to understand, "How can you meet the goal that you've set forth?" So for example, if you're going to San Francisco, my goal is to get to San Francisco. What is the absolute minimum way that I can get there? Could it be like in a Flintstones car? Could it be on a bicycle? Could I walk there? How do I achieve my goal and understand if I'm actually achieving that? I think that really comes, that MVP is really defined, by what goals you set. And that also informs the other steps to understand if I'm failing. You have to know how you're going to fail. That also defines how you're going to succeed. And if you haven't thought about that before you build your MVP, or your minimal viable experience, then you won't be able to understand if you're succeeding or failing.
Kelly: I really want to come back to this concept of thinking about how you're going to fail. Let's make sure we talk about that. What are we talking about when we talk about lean, Tami?
Tami: To me, it's really about the build, measure, and learn, and the experimentation. Because by experimenting, you're setting yourself up to learn something. So an MVP, this minimum viable product or minimum viable experience, I often like to say minimum learning product. It may not actually be software. It may not actually be a physical product. It's a way of saying, "We have these assumptions out there as to what a user wants. How can we quickly test that so that we don't invest too much? How can we minimize our risk of investing too much time and too much money and too much resources going in the wrong direction?"
Like you said, become so in love, or assume you love something so much because you've invested so much team hours or money in it, so at this point, it has to work. As someone who's made early stage investments, I often think about that when I see some more money poured into a product which I think is an absolute dog. I'm like, "All right, at some point, if we just thought we'll throw more into this," rather than staying lean and saying, "You know what? It's not going to work."
Tami: And that's where a lot of lean emphasis goes into is, "How do you test and measure?" That measurement, how do you establish key performance indicators or KPIs that'll help say, "We're heading in the right direction," or, "We're not, and we need to pause." It's so important that if the data's not telling you you're going where you want to go, to stop. If we're still trying to get to San Francisco, but the roads are blocked, maybe we should hop on a plane.
Kelly: Change our route. But you know, some of this is a...talking about KPIs, sometimes do we rely on those too soon? I'm looking at you, Nikki, and rather than saying, "No. No, we have to keep going a little bit further. I know that we're not meeting our KPIs, but this is the right route."
Nikki: Yeah. I think it's really hard for some people to define the KPIs and then actually be open to seeing what the data says. I'm a big believer in analytics, a big believer in metrics. I put analytics in everything that we do. I think sometimes, for various reasons, people don't want to actually see the reality of what's going on. Maybe because you have pressure from a boss. Perhaps someone more senior than you is saying, "No. This is the direction that I see." You have a lot of CEOs out there with a lot of ambition, and with ambition comes idealism. They have great ideas in their head that they want to see achieved, but sometimes their gut instinct is actually not right. It's really hard for a product person to come back and actually say, "I know that you wanted us to try this, but it's actually not working."
That's kind of one of the hardest conversations you can have as a product person working with kind of an ambitious CEO. The reality is sometimes you're going to come back with really hard news. I think one of the challenges that you have as a product person, a great challenge, is really coming back and saying, "This thing might not be working, but I have another idea that might." Or, "From what I'm seeing from the data, here's actually how we're seeing users use this new feature. It was a way that was unexpected, and here's an insight we have from this that might actually shape the product for the better in a way that was unexpected." But you have to be open to seeing that. That's actually something that I would say, having that perspective, and being kind of open to these new things is something that I also look for for product team.
Tami, I'm seeing a lot of nodding from you that listeners of course cannot see.
Tami: I couldn't agree more. And something that hit me was good product managers know how to say no. That's an incredibly important skill. It comes into that prioritization I mentioned earlier, but being able to say no is one of your strongest skills as a good product manager. Because if you just can take someone else's vision and make it happen, that's more project manager, right? Product managers say, "This is the wrong thing for right now. Here's an alternative."
Nikki: The other thing, if I can add on that. Being a good product manager is also being the evangelist for the user. Often times in organizations, there are reasons why you put out new product features that have nothing to do with the end user. It might be a marketing ploy. It might be something that you're pushing a product. And you really need to be the one that says, "You know? This doesn't feel right. Maybe this is off-brand, or maybe this is an intuitive, or maybe this is something that feels a bit icky for various reasons. Maybe you're just like feeling into your gut, and you just know it's not right. That's actually the job of the product person to be able to say, "You know? I am the advocate of the user, and we're not providing the best experience to them."
Kelly: And Allessandra, I'm looking at you because you have led some product at Shapeways that have been used by, I would say, all of their users. Does that resonate with you?
Allessandra: Yeah, absolutely. Absolutely. And I think, you know, speaking to Nikki's point about it being difficult to say no. I think it's also really important to be able to advocate for the things that you think are really important for the user. So that dichotomy, I think, is really based in having a really good understanding of what your goals are as a company. So very high level goals of, "What is the strategy we're trying to achieve? How do we want to get there? What is meaningful to our customer? And do we want to acquire new customers versus retain our existing customers? Do we want to have better engagement? Do we want page views on this certain page?" It's much easier to say no or to advocate, "Yes. We should absolutely go down this path and build the product with this vision" if you have a common understanding, not only cross-functioning across your company, but also up and down of what goals you're trying to achieve are.
That makes that conversation around no much easier because it becomes much less emotional, and much less, "Your gut instinct is wrong." Which is of course never how you would end up phrasing it, but it makes that conversation much more based on data rather than feelings and kind of emotion around the product. Because everyone gets incredibly invested in the product you're building. If you're not invested in the product you're building, then you probably could be putting more into it. But I know working with my team and various teams that have built products before, it's always a difficult conversation to be really comfortable with saying, "Actually, we need to remove this feature. This feature is not succeeding," or, "This product, actually, is succeeding for an entirely different audience," which we would classify that as failure. Because that's not why we built this product. Then, you have the difficult conversation of, "This has failed by our definition of success, and by the goals that we set."
Is this something we want to pivot to this other audience, and say, "New users love this so much more than our existing users?" or do we say, "You know what? This isn't actually why we built this product. We have a lot of other products and features coming down the road map that we want to execute on. Frankly, we don't have the resources and we don't have the time. It's a really good piece of learning that we should keep in the back of our minds and integrate into our road map, but ultimately we should kill it." And again, I think one of the things that has made those conversations incredibly easier than they could have been was just having good goals up front. I've certainly been in the position where I haven't set those goals very well up front, and then it's very difficult to have the conversation of, "Oh. Are we succeeding?" because you don't know then.
Kelly: If you don't like the goals. This leads into our favorite in the startup tech world, failing fast. Tami, failing fast. What does it mean? And how should we be thinking about that? Because it has so many connotations, and I'm going to say it, so many connotations when I'm sitting in a room full of women. Failure is not...we don't want Miss Congeniality, we want the crown, and we sure don't want the failing fast or the failure banner.
Tami: I think that failing fast is kind of been overplayed. Because I don't want to think about it as failure. I think we need to transition away from the concept of "Something has failed," to, "What did we learn from this?" Because we teach this to small children, right? It's not a mistake, it's a learning opportunity. That's the same thing when it comes to building products. It's not a failure if you actually learn from it. Sure, your launch was not a success, right? You launched a product and you thought you were going to get $100 million in sales, and you only got five. What did we learn about this? Was there a marketing issue? Is the product not meeting the user's needs? Was there a competitor that showed up with something better that you didn't anticipate? All of these things could happen. The marketplace is complex. So it's not necessarily that you've failed, it's that you didn't have success. How can you learn from that experience and see the full picture so that you can, next time, be more successful?
Kelly: I was going to say. I'm the one sitting here nodding in agreement, because I always sort of think of failure as if you don't learn from your mistakes, and you keep making the same mistake, maybe that's a failure at that point. Nikki, thoughts on how you approach failing fast?
Nikki: Yeah. I mean, I think about it the same way that Tami does. I actually think that all of these things are really just learning experiences to how you can kind of better the product for the future and also better your own intimacy with knowing your user and advocating for them in a way that maybe you didn't think of before. One thing that I learned, talking about kind of like how to fail, I think we also need to be aware that there are sometimes pressures from outside of your work place that make you make product decisions kind of rashly. I worked specifically on some apps and it's really important when you're working on apps to have a good relationship with Apple, because anytime you produce an app it has to go through the Apple Store for review.
The review process is quite difficult. It's something that Apple really loves to ding people on and keep your apps outside of the store. The other thing that's the positive is that if you really work with Apple and you say, "We have this great app. We want you to promote it." The app really needs to be up to Apple's standards, meaning it has to follow all the Apple guidelines for design, it has to have the right code, and it's something that a lot of teams really go to extremes to meet in terms of Apple. And I've had a recent situation where working at Christie's Auction House.
The mean age of our user is around 50. So if you're a 50-year-old individual, you're probably very familiar with apps. You know what they are. You have an iPhone. But you're not super tech-savvy. So when we went for an Apple review recently, they came back to us and said, "We want you to change the design of your app. We want you to get rid of a lot of the terms that you have. We want you to use buttons that don't have any words on them. We want you to put in what we're calling a hamburger menu. We want you to change the design. We want you to change the colors," and we listened.
Because we thought, "Okay. Well this is Apple, and to meet Apple's standards, and they're supposed to be providing us the best practices, we should do all of these things." We changed the design of our app completely and put it out in the app store, and only found out that our users came back with a ton of complaints. They had no idea what the menus meant anymore. Hamburger menus don't mean anything to a certain group of people. They actually just want the word that says "menu." So getting rid of the words was actually really something that was a detriment to us. They found the new design to be really confusing. They didn't like the typography that we used, because to a 50-year-old with certain glasses, that's actually hard to read. So we went back and actually had to say, "Wow." We took the advice of this outside company kind of just negating that we know our user. We know what they're looking for. We know what they need to do. And we went back and changed the whole product to now add in tool tips, to add in a tutorial, to add in kind of steps to make the app actually more intuitive. And it goes completely against Apple.
We had to have this really hard conversation with our Apple representative to say, "We know that you want us to do all these things. They're not working for us. For our user, this is not appropriate." And it was actually a hard conversation to have, but a really good one to have, because we knew what our user wanted. Then we saw our reviews again in the app store go right back up to positive reviews. It was actually great to see people write, "I'm really glad that they changed the design of the app back. We like the old design better."
So it was kind of a failing fast, but also learning a lot from that, and learning kind of that we have to listen to the feedback that we're getting. I think one of the things in being a startup is that, you know, agile methodology has been something people have been touting for a while now. It's the idea that you're really being iterative at a very fast pace. The problem with iteration at a fast pace is that you're actually confusing your user sometimes. Sometimes it really takes a while for a user to get comfortable with something. The faster you do that, the more confusing it is.
Kelly: And I'm thinking particularly if you have an audience and a user who is making deliberate thoughtful decisions on something that is of a class of object that very few people could afford. You're looking for more explanation than just an image, and that sort of resonates.
Nikki: Well even the way that Apple has share buttons now. It's just an icon. People have no idea what that meant. It's on their phone. They just couldn't translate that that thing on their phone was going to also be the same thing that was in this app. They just wanted to see the word share. That was all.
Kelly: Show me the word. Give me the explanation. Allessandra, before you brought up a concept of planning to fail. What do you mean by that?
Allessandra: Well, I think...
Kelly: Because most of us want to plan to succeed. That's why I asked. What do you mean by planning to fail?
Allessandra: Yeah, absolutely. So I think one of the things you have to think about when you are deciding what product you're going to build and what feature you're going to build is understand, "When are you going to get in touch with your user?" At what points are you going to look at your product very deeply and understand if it's actually being successful? Some of those points are very early on. For example, you know one of the products that I worked on, CustomMaker, which automatically customizes a 3D model if you want to put your name on it, or you want to put a picture on it, and then you can 3D print it. We did a stealth beta. When the product actually wasn't even functional, you could barely use some parts of it. But we planned it early on, because we knew that for certain pieces if it failed that early on, we were going to have to probably delay the product launch and dig much deeper to find a different paradigm to show to the user.
And luckily, most of that succeeded and we were able to move into a full public beta of an actual functioning product, and then move it to a majority of our users. But you need to plan when you're building the product of, "What are the points of no return?" where I need to make a decision here with my user, and truly understand if I'm meeting their needs. And if I'm not, that's okay. I've already thought about alternate paths. I've already thought about different conversations I can have with my user and alternate products that I can build. Or I can go forth kind of to the next road stop, or the next pit stop that I was planning.
So if you have already built that in, and especially if you communicate that very broadly, I'm definitely a fan of overcommunication. I would rather have every single person in the company know what the possible avenues of failure are and success. Then that conversation becomes a lot easier with both your user, if you're very open with them, and you appreciate their feedback, and really encourage them and say, "If you tell me this isn't working, I'm going to take that back. It doesn't necessarily mean that I'm going to change my decision, because you're one user among many, but I really do appreciate your input."
Kelly: The ability to be heard, which I'm sure your users, I'm looking at you, Nikki, your users at Christie's just being heard. I want to get into the weeds with how the lean startup approach has affected a particular product development. And Tami, I really would love to talk about what your team at Cyrus did with building Just Not Sorry! and how you used the lean approach in building that Gmail plugin. And so if you could, first of all, say, just in case someone missed the news on what Just Not Sorry! is, if you could talk about that and then how your team approached that using lean methodology.
Tami: Sure. Just Not Sorry is a Gmail plugin that underlines words like "just," "sorry," "I think," "does this make sense?" and other words that diminish your message and make you come off as less confident in Gmail and Chrome. We launched it December 28th, and as of today we have 100,000 users. So in a little bit less than a month, it's had a lot of viral growth. What we use from a lean perspective that made us know we were going in the right direction was that every step along the way, we talked to users. So when I first came up with the idea, I mentioned it to a group of people, and everyone said, "Yeah, I would totally use that." But that's not good enough validation for an idea. What my friend Steve has taught me is that in order for you to know you're heading in the right direction, someone either needs to be able to give you their time, their money, or their social capital.
That's what validation's all about. There was one person out of that 12 that represents a PR firm called Small Girls PR. Her name is Kara, and her response was, "Not only will I use it, I'm going to give you free PR for that and I will spread the word." And that's when we knew that someone was willing to give up their time, their money, and their social capital, and we were on to something. As we railed out beta users, everybody said, "When can I share this with my team?" So that nature made us know that we were really on to something that people would love. But we iterated on the name of it. We iterated on our landing page, because the day before launch, I sent it to three friends of mine who didn't know what we had built.
I said, "Hey, check out www.justnotsorry.com. Tell me what you think." They said, "Oh, this is so great." I said, "What did you think of the plugin?" And they said, "What plugin?" because all they had done was sign the pledge to be a more effective communicator and try to eliminate these words. So we reoriented the entire landing page so that point number one was download.
Kelly: You must download. I'm Canadian, so I'm like, yeah, if you had that plugin for Canada, everything would be highlighted. How many times do we as Canadians say, "Sorry!" Then was your entire team at Cyrus involved in this?
Tami: No, it was a really small team. We had a developer that wasn't assigned to one of our clients, so generally Cyrus provides developers to help other people build products. So we had a developer that was what we call on the beach, and in around four days he built it. We had another developer who was available for an afternoon based on Christmas breaks and stuff, so he came in to help with a little bit. Then we had friends and family help with PR, and now we have developers that are maintaining the open-source code.
Kelly: And why'd you open source it?
Tami: We're not perfect. We knew we didn't have all the answers of all the things that needed to be underlined. And we didn't plan on this being a sustainable product that we were going to sell licenses to. We wanted this to be a community thing so people can actually suggest new things to underline. So the two biggest changes we've had since we launched are that the underline now is more distinct from spell check. So instead of it being a red underline, it's now an orange with dashes, and we had the open-source community approve that. And then someone suggested "try" and "trying" should be underlined, and so that one's attributed to Yoda because, "Do, or do not. There is no try."
Kelly: I love that. And I will say I am one of your current users, my view being that anything we can do to improve communications in a world where we're using emojis, and we're texting, and we're tweeting in 140 characters, sometimes that thoughtful communication is lost. And I think that anything that helps us communicate better is a good thing, so good work on that. I want to kind of go again, staying sort of in the weeds, and use a case study. Let's use a hypothetical here to really help the wanna-be entrepreneur who has a great idea. So that classic story we hear about that non-technical founder with a great idea needs to create an MVP in order to hit up people like me for money, or their parents, or whoever else, their friends and family. And they don't know where to go about and how to go about hiring a technical team.
So kind of with that in mind, Tami, why don't I start with you again? What is your advice to someone to how they even start the process of thinking about how to approach hiring a technical team? And then we'll kind of keep with this example, we'll call her Jane who's our wanna-be entrepreneur with no technical background. Where do you even tell them? What's your advice from the start?
Tami: So, from the get-go, to be a successful entrepreneur, especially in the tech community, you have to be technically literate. You don't have to be able to code, but you need to be able to speak the lingo, and each product's going to have a different set of lingo when it comes to what technologies they're using and how they're building. But you want to find an engineer who's going to help you become more and more literate. So the way I see it is, when you ask them a question, they need to be able to cover three things. The first thing is that they repeat back to you what you said in a nice way that shows that they understood your goals, right? The second thing is that they say, "I evaluated a few different options, and then I chose this one because I think this aligns with your goals." So that's the second and the third one together.
But they need to be open-minded about new technologies, about building things in a way that they aren't necessarily familiar with, and then they need to be able to tell you very clearly why they're choosing one option over the other so that you can choose. Because you are the owner, and it is you who has the funds that are being put forth towards this. So that's what you're looking for in an engineer, someone who's going to help you understand what they're doing so that you can become more and more literate. Because chances are the first engineer you hire isn't going to be the last. You're going to have to be able to explain to the next engineer and the engineer after that what it was that was built, why it was built in certain ways, and how that aligned with your goals at that time. And then later as your goals shift, the technology is probably going to shift too.
Kelly: I see a lot of nodding from Nikki and Allessandra.
Nikki: Oh, yeah. It's huge. The relationship that you have with your tech lead, it's kind of like getting into a marriage with someone. It's like really trying to find the right partner. But it's almost, to Tami's point, it's like for the right period of time. The thing is that, as a founder without technical knowledge, I think that, as Tami said, it is really important to kind of like ingratiate yourself with certain kind of understanding of what it is that you're looking to build and what the options are. Generally, in a startup, you know that you have a great idea. You know that you have a certain amount of money which is to get that idea out there. So you're kind of in this place where you have to make three decisions. One is kind of...and again, it's always that thing of cost versus speed versus quality.
So you might go with the quick and dirty, which is option number one, which is you saying, "Okay, there's some open-source code out there that we can borrow." And maybe I'm going to have this tech person who I hire kind of manipulate this code in a very cheap, easy, fast way. The second thing is maybe a level higher, which is, "I'm going to license something that already exists." Maybe get on a platform that's already out there that you can quickly kind of get your application or get your product up and running, but it's a fee that you're going to pay to a monthly service. And you're going to have this tech person kind of help you get on there, maintain it. The third thing is the most expensive, which is, "I'm going to customize and make something from scratch myself." That's also really having a lot of trust in the tech person of saying, "Okay, I believe that you're going to actually build this thing from scratch for me, and you're going to get it up and launch it."
I think it's something that again, as we discussed earlier, it's kind of like, "What are the KPIs that you have from the onset of the project?" Is it that speed is what's driving this? Is it that cost is what's driving this? Is it the quality? Do you have something that's really so specific that there's nothing out there that exists that you really just need to customize your own thing, in which case you have to say, "I'm going to be okay with waiting a long time for this to get out there, because I know that it's so important that this is customized to me." And I think also in finding and searching a whole co-founder or finding that tech lead, it's really important that they understand what that KPI is for you. That's the most important, because as Tami said, you need someone who is going to help to explain to you the things that you don't know.
So if there are seven options out there of something that you can license, and you're having this technical lead look at all of them, they need to be able to come back to you and say, "Here is my best suggestion. This is why I think it makes sense for us. Here's how we're going to grow in this platform. It's the best option for our money today." Whatever it might be, you need to trust them. I think having trust in that person is the most important thing. For most people you know kind of what your own capabilities are and where they kind of stop. And so you have to trust that that person is going to be giving you the same thing.
Kelly: And having gotten into their head, so you know how to trust them. Tami, and then I know, Allessandra, you've got a thought, but Tami?
Tami: I want to touch on something Nikki said about the nature of the marriage. Very often I see entrepreneurs out there. They say, "I'm looking for technical co-founder." That's saying, "I'm looking for my partner in life right now. We're not going to date first, but we're going to meet and then tomorrow we're going to start as co-founders, and I'm going to give up a large equity share to you." When in reality, what you should be doing is dating. You should be saying, "Hey, let's work on a short term three to six-week project together and see if we can work well together." See if they can answer those questions. See if you can communicate effectively with each other. And then say, "Great. Now let's move on to a six-month contract," or something else, and then offer them CTO co-founder share stuff. Because unraveling that is a lot harder than anyone ever imagines, equivalent to unraveling a marriage. So why wouldn't you date first and try before you buy?
Kelly: And that advice, to me, sits right on top of this advice of maybe you build your product. And all right, I can use some open-source code. I can build off an existing platform. Now I can customize because I've dated, and now I know I've got my CTO. Allessandra, I know before you had a nod and a comment and thoughts on some of the things that Nikki had said.
Allessandra: Yeah, absolutely. Just building off some of what Nikki had said. When you are building up that partnership, I think it's equally important to understand what value that you bring to the table as a non-technical co-founder. I think it can be very easy to get a little bit nervous or start to doubt yourself a bit when you get into kind of the technical weeds of the product that you're building. Because it can be a pretty difficult ramp-up, depending on what type of product that you're building. And as you go through that process, with a good partner, and also just being a good founder yourself, you really have to understand what you are bringing to the table versus what your technical co-founder is bringing to the table. As long as you are very sure of that and your technical co-founder is very sure of that, not only does that strengthen the relationship between the two of you because you both are confident in your inherent value, it also helps you through the more difficult times when you're dealing with problems that you've never encountered before, which is certainly something you're going to be doing when starting a company.
Kelly: Thank you for that. I was just thinking, I want to go back. Tami, you made a comment of, "You need to be technically literate." I'm very familiar with Skillcrush. Are there other books, courses, programs, that any of you would recommend for...Allessandra, let me look to you, that you would say, "Hey, if you're a non-technical founder and you need to know this language and understand...so if someone throws out Java versus Ruby versus Python, open source, whatever it may be." You're in their mind, so you're looking at the technical person as the creative partner to what you're building, not the plumber who's coming in to fix something.
Allessandra: Absolutely. Wikipedia, for me, has been one of the best resources to get on top of new technical topics that I'm not familiar with. And that may be before I'm talking to a new colleague who is a technical lead of an area that I haven't worked in before. It could be after I've spoken to that person. In learning a new technical subject, when you're speaking with your tech lead, having the humility to also acknowledge that you may have no idea what they're talking about. If they're a great tech lead, they will take the time to explain that to you. But if you're doing it before or after hand, I have just found Wikipedia to be a really great resource. For example, I've worked in 3D printing, and I knew nothing about 3D models before joining Shapeways. So I spent probably three to four hours on Wikipedia understanding what voxels are. They're 3D pixels, essentially. And that's very different from polygons and triangles, which is another type of mesh that makes up a 3D model. It's a really great introductory level to kind of click around. You can just get lost and understand all these tangential subjects that may not have come up in your technical conversation, but are important background knowledge.
Kelly: Wikipedia's having an anniversary. Aren't they going to like this little comment? Tami, any resources or things you'd say to people, "Hey, go here and get up the curve."
Tami: Well, I totally agree with Allessandra. And something I also encourage people to do is Googling whatever the word is, and then adding versus to it. So Google will auto fill in what a competitor is, so if you type "Java vs something", you'll see what the other options are, and then you can research the other options as well. So if you type in Shopify, it'll Shopify vs other ecommerce platforms.
Kelly: So as you don't have to put in what the others are. It'll pull up all those others, and you can say, "Oh, if I want to build on this, or I want to do this, or the dev shop is telling me we should build this in Ruby and I want to know what the other...okay."
Tami: That's a really good way of seeing that, because more informed people are weighing those options, and they say, "Shopify vs Magento. Is this the right decision?" So they've already typed that in countless times, and you're leveraging the community of people that are trying to comparison shop to your advantage.
Kelly: So using internet search as a tailwind for getting yourself up the smart curve on all of this. All right. I want to get to our pay-it-forward section. This is our series of nine questions we ask every guest. We'll do this rapid fire. Ladies? So start with you, Tami. Everyone's going to get the same question. So our first question is, what are your go-to sources of information you use every day?
Tami: I was your inboxer, so a lot comes through my e-mail. When I look for outside information, it comes from Twitter and Facebook.
Nikki: Facebook and The New York Times.
Allessandra: Facebook and Wikipedia.
Kelly: I should have known that Wikipedia was going to be on there. I'm going to start paying more attention to Wikipedia after this podcast. How do you discover new information? Allessandra, let me start with you.
Allessandra: Either through my mentors or e-mails. I love this e-mail series called theSkimm. Really great way to, well, have a funny read and really understand what's going on in the world. And then I usually follow it up with Wikipedia to understand things that are going on that I may not know as much about.
Kelly: Very smart female-founded company.
Nikki: Yeah. I also love theSkimm. In addition to theSkimm, I definitely skim TechCrunch every morning, and also read Fast Company and other various kind of more, I'd say, tech-focused blogs or magazines all the time just to kind of stay current.
Tami: I would say that recently LinkedIn, the news feed there has actually been coming up with a number of really interesting articles, whether in ink or Fast Company for me to read. So LinkedIn at the moment.
Kelly: Who would have thought? Maybe they're finally getting their media piece right. Let's go old school. I'll start with you, Nikki. What book are you reading?
Nikki: I'm reading The First 100 Days of Leadership. I'm starting a new job soon, and so it seemed like a good thing to kind of think about my first 100 days what I'm going to do there.
Kelly: Are you going old-school publishing or you're going digital reading it?
Kelly: Digital. Okay.
Allessandra: I'm reading a book called Crucial Conversations. It's actually something that I read about 10 years ago. Really, really great book. I actually just recommended it to somebody the other week, and I was like, "I should reread this." So I'm doing that.
Kelly: Crucial Conversations. Like it.
Tami: I'm in the middle of Disrupt Yourself by Whitney Johnson, which is all about how women very similar to the ones in this room are high achievers, and that often leads to us being perfectionists, and not being okay with things that have errors, and being public about that. So that's what I'm reading right now.
Kelly: Love Whitney. Love Whitney. Who are the people who have most influenced your career? Allessandra?
Allessandra: My managers and my mentors. Actually, most of my managers have become mentors for me. All of my mentors are male. I've never worked for a woman, and I've had very few female colleagues. I've had people ask me before, "Is that a problem? How do you learn?" I have some of the best mentors that I could have ever asked for. I rely very heavily on them for career advice, helping me negotiate, helping me understand what's best for my career.
Nikki: My parents, actually. They're both pretty successful business people. I look to them for advice in most things, whether it be negotiating for a new job, or kind of management styles. They both have led really large teams, and I think they've done a great job. So I look to them when I'm making big decisions.
Tami: Recently I've been turning a lot to our clients. Because most of our clients are CEOs, CTOs, COOs, and so seeing their perspective and really leveraging their experience, because very often they're at least a decade older than I am, has been really, really great.
Kelly: All right. The next question. I'm going to start with you, Nikki. You did give us some best advice, so you might have to give us...it was the second best advice. But what's the best advice you've received?
Nikki: I'm going to have to double down on some of that advice and just say, "Keep perspective." It's something that it's so valuable, and it's something that gets really lost. Especially, I would imagine, if you are working at a startup and this is something that you've put your blood, sweat, and tears into. This is your baby. You're putting your life savings into it. Just kind of keeping the perspective that this is so important and so crucial, but there are many other things that are going on in your life. And there are many other things that are going on in the lives of your colleagues. It's really important to kind of just remember the perspective of kind of what these decisions are that you're making, and how they kind of play out versus the rest of your life.
Kelly: Best advice, Allessandra.
Allessandra: The best advice I ever got was to be comfortable with being uncomfortable. I'm not the most naturally assertive person in the world. It took an amazing colleague of mine at Microsoft who was incredibly assertive to really get me comfortable with pushing back and especially when I have not as much information as everybody else in the room. She just really pushed me to be comfortable sometimes being uncomfortable, and letting awkwardness sit in the conversation to really drive home a point, and to kind of level the playing field with some of my other colleagues.
Kelly: That's great advice. Tami?
Tami: What's the worst that could happen?
Kelly: We're not brain surgeons. We're smart, but we're not brain surgeons.
Tami: It's not rocket science. There's no one on the table. All to keep in perspective, but it's that perspective very specifically. What's the worst that could happen? When you're running an experiment, what's the worst that could happen? When you send out an e-mail, when you pick up the phone, what's the worst that could happen? They say no, right? So that's the perspective that echoes in my brain.
Kelly: And if you listen to Gary Vaynerchuk [SP], he loves a no. Eats no for breakfast, because that gives him more drive to succeed. All right. You know, I want to say the power suit. What's your wardrobe item that you pull out when you want to feel strong and bold? I know what mine is. Allessandra?
Allessandra: I definitely wear a dress. I love Calvin Klein dresses. I have probably 10 of them. And when I want kind of like a power woman day, I just wear one of those and it doesn't matter if I'm by far the most dressed up person in the room. Because I'm transitioning jobs right now, but at Shapeways, I worked extremely casual culture, but it made me feel awesome. And if you wear it with confidence, then no one's going to say anything.
Nikki: I'm going to have to go with a statement necklace. I guess, statement piece of jewelry, I think, goes a long way. I think most of us naturally reach for that power suit, as you said. Put on your blazer, and nothing goes better with a blazer than a statement necklace.
Kelly: And you have got a great one on today. I have to say, being at Christie's, there's been more than a few nice statement necklaces I've seen. Wait for one of my startups to exit so I can use your app and buy one. Tami?
Tami: I actually have a cute little black cropped blazer, because I don't tend to wear things with sleeves. I grew up in Miami, and then lived in L.A., so I have a very wonderful collection of sun dresses. So there's something about putting this little cropped blazer on it that brings a sense of elegance and importance to what I'm doing. It also hides that I'm really nervous. So rather than feeling like, "Oh my God, I'm sweating and nervous and everyone can tell," it's all covered by the blazer.
Kelly: Yeah. Blazers cover a variety of sins. Then the last of our pay-it-forward questions. How do you pay it forward?
Tami: So I mentioned earlier we have this female founder hour program, so anybody can sign up for an hour of product strategy with me. Whether when I was at Pivotal Labs or currently, I have a pretty high per-hour rate to sit down and work with product strategy with someone. So we give that out for free for all of our female founders in the community. We also run a number of events where people can hear about different perspectives. We have one event series called Agile at Scale, which we're launching in February, where people can learn about how to use scale agile practices at larger organizations. And for the female founders, we have something called Ten Things Every Female Founder Should Know.
Kelly: And where can people find information on that?
Tami: Both of those are available at cyrusinnovation.com. We're working on an events page right now.
Kelly: Cool. Nikki, how do you pay it forward?
Nikki: I've definitely started to provide mentorship for some of the more junior product people on my team, whether that's going to coffee, or kind of just like taking them under my wing in various situations. I've also started working with a group called Out in Tech and providing, similarly, some mentorship for young lesbian and teen youth who are looking to kind of get into technology.
Kelly: That's fantastic.
Allessandra: I also love being a mentor. And definitely try when new interns or new employees come in, especially in a product and tech team, to take time to listen to what their experience is, make sure they're set up properly, and whether that's at my company or another company, I'm really trying to build that kind of network. I'm also a big advocate of the ONE Campaign that Bono founded, and it's for political advocacy. So that instead of going and necessarily building a house for someone, you're really advocating for the government of that country to go build a house. And one of their big themes is equality for women and really supporting women so that they can go build their own businesses.
Kelly: You've all paid it forward by A, being here, and B, I want to say continuing to do what you do in staying in your careers. So I thank you personally for that, and thank you for being here today on BroadMic.
Tami, Kelly, Allessandra: Thank you very much.
Kelly: Thank you for listening to BroadMic. We welcome your feedback. Find us on Facebook, where you will have show notes and additional references for a deeper dive into today's topic. Subscribe on iTunes so you never miss an episode. Please review our podcast on iTunes, which will help other listeners discover BroadMic and grow the BroadMic community. BroadMic is produced by Christy Mirabal, with editing by John Marshall Media. Our executive producer is Sara Weinheimer. Think Broad.