Rick is the multi-time, product-focused founder. In our time together, we cover how you can make better product decisions inside your startup. Enjoy.

Rick, thanks for joining us today.

Rick Orr: Hi, William. Thank you for having me.

William Griggs: We really appreciate your time. The goal of the interview is pretty simple. We want to help the founders and CEOs in our audience listening to this podcast right now make better product decisions inside of their startup.

We had a guy on recently, Luke from Silvercar, and he was talking about how you can spread yourself too thin, and if you spread yourself too thin, that’s one of the quickest ways to go out of business, so we want to help people avoid spreading themselves too thin on the product side of things.

Before we dig in to the product side, product strategy, and product management, you’ve got to give us a 30-second overview of your background, including what you’ve accomplished and what you’re currently working on.

Rick Orr: Certainly. This is my, I believe, 17th year – no, that’s not true – 21st year in Austin since attending UT as an engineer. I came out of engineering school thinking that I was going to be a lawyer, and quickly fell in love with the technology space we have here in Austin, so I think I made the right decision.

My college roommate reached out to me just a few months after graduating and said, “I’ve got this idea. We’re going to go detect Trojan horses and phishing threats in a company called Whole Security [inaudible] [00:02:06] lead product, and help us build our first backend. I was kind of a cruddy developer back in those days.

Whole Security was my first startup. It got me addicted to this rather insane life of starting companies, but I got a front-row seat with my buddies there. We took the company from, in three rounds of funding, all the way to an exit, to Symantec in ’05, so it was a great experience.

Then I met up with some of the other local entrepreneurs who had founded NetSpend. They had a new company, very similar, internationally play called Rev Worldwide. I spent some time there, and then finally went out on my own for the first time as a first-time founder and CEO with TabbedOut, which is a mobile way to pay for your bar and restaurant check. I still continue to serve as a director at that company.

During the span since ’98, I was also a real estate agent on the side. As I started to near my – well, in my late 30s and near my 40 mark, I figured since my wife will let me do this a little bit longer, I should probably go start another company because that’s what I enjoy doing most, and I started RealSavvy. RealSavvy is a culmination of my front row seat to the real estate industry, which really hasn’t evolved in favor of agents the way we think it should, so that’s what we’re working on today.

William Griggs: Got you. Very cool. That’s a good background, a good overview for the audience. It looked like, as I dug in and did my research, that a lot of these companies you’re working with, you’ve held a lot of different product management level jobs, and that’s kind of the topic for today, so let’s dig in. How does that sound?

Rick Orr: That sounds great.

William Griggs: All right. As far as cutting to the chase and helping people right off the bat, what are some of the biggest mistakes, biggest product strategy mistakes you see people make?

Rick Orr: You alluded to it at the start. I think Luke is right, from Silvercar. It’s spreading yourself too thin. I’m a big proponent of a methodology and general philosophy from Geoffrey Moore that many of us know called the bowling pin strategy. It exists for a very important reason. Especially with small teams, you can only really accomplish one thing well. Even then, you’re only going to get it maybe 70 or 80 percent right.

I think avoiding the, as you mentioned, spreading yourself too thin, avoiding the temptation to do too much too early is one of the key things in building products. Not enough people, as today’s technology has evolved to the point where you can very cheaply try things, take the time to do primary research, to paper test concepts before you start building them. I think that can save you a lot of heartache.

It can save you a lot of cultural erosion, particularly amongst engineers, and your product team, and product making counterparts if you don’t take that time to really think something through, and get it to paper before you write the first line of code.

William Griggs: Got you. Can you unpack the bowling pin strategy? I don’t think I’ve ever come across that.

Rick Orr: Sure. I had the good fortune of working with one of Geoffrey’s counterparts, a guy named John Metcalf. I give all credit to him for sort of restricting the way I think about things. It’s perfect for your double-sided marketplace. The likes of Yelp, even Stack Overflow are good examples of those that have deployed the bowling pin strategy.

Like bowling pins, to get to the next row of pins, it’s best to make sure you hit the first one crisply, and make sure that he momentum from it falls into successes and other, in this case, pins. Those pins could be additional markets, like the Yelp model where they sort of validated critical mass, got to critical mass in one market, and then rolled out their strategy across the country. It can be Stack Overflow where they started with developers but they have cooking-related things now where people kind of in the forum can talk about it.

There are a lot of great examples of where, if you focus on the lead pin, it gives you the options you need as a company to choose which path you want to go, which can either be to go to the next product feature, go the next market, go to the next vertical. It’s really all possible, but first thing first is to make sure you pick something that’s, as John Metcalf always said, big enough to matter, small enough to dominate, and self-referencing.

Those are the ways that we – at least I have always tried to find a product path with my teams to go after markets.

William Griggs: It seems like spreading yourself too thin or building too many things is kind of a result of not really having that strategy. They’re not really taking a step back, like you’re saying, and thinking through what’s essential, and what’s going to lead to the other pins falling down if you get this one right.

You talked a little bit about primary research, and paper testing. Can you talk a little bit more about that?

Rick Orr: Sure. I actually recently spoke at a conference around something called ProtoHack where they’re trying to get people who don’t write code to launch businesses with confidence. You can use things like Marvel app, or if you have cursory level access to design skills or design platforms, you can really produce an app or produce a concept that you put in front of real people very early, and in some cases, that can just be PowerPoint slides that you print out. In other cases, you can use these sorts of platforms that are refereeing to on the prototyping front.

The concept is very simple. It’s – even the best of us. I’m in this space now, one that I’ve been an actual participant, technically a customer of what we’re building with Real Savvy, for 18 years as a buy side agent, an agent representing buyers. Even as a part-time agent, I understand the pains really clearly, but at best, because I’m not full time, and we’re focused on full-time agents, I can get it 70 percent right or 80 percent right if I really take the time.

What we try to do is put what we think is the solution for these agents down to paper, and sit, and have lunch with them. In the early days of RealSavvy, it was a PDF we had them go through. “Does this make sense? If you were inviting a client, would you do this? “You can watch where people’s fingers go on paper, and it makes tons of – honestly, it builds a lot of confidence, particularly if your team doesn’t have the same context you do with the problem, that other people are validating the direction you’re going in. That’s what I mean by paper test.

William Griggs: Got you. That’s a good one. I’ll put some links to that, ProtoHack, and a few tools. There’s InVision, and UXPin. I’m not familiar with Marvel app, but I’ll check it out, and link it up in the show notes so people can go down that direction.

It seems like so far we’re talking about taking that step back, thinking about what’s essential, thinking about that bowling pin strategy. What can we knock down that’s going to make the next step even easier? How can we get that first row of pins knocked down cleanly and crisply in a way that proves that we know what we’re doing, builds some traction, builds some momentum that we can continue forward with as we go forward with building the business.

As you’re building RealSavvy, how do you think about your overall product strategy, and how do you start to define that out?

Rick Orr: So we can’t do it all. We’re a five-person team. Again, the theme is that. I look at our roadmap and the way we approach our product strategy as very much one and the same. We need to achieve early product market fit for a small group of people that love what we’re doing, and Sam Altman and Paul Graham have a great series out of Stanford on that very thing, so I’m purely stealing that statement, but I believe it immensely.

You build something that a few people love, and that’s something you can accomplish. You can talk to those people. They’re a small enough group to get the iterative feedback that you need, the lean startup, and the other methodologies all touch on the same principle.

What we do with product strategy and roadmap is we try maybe, as a loose analogy to chess, to put the pieces together so we can get someone to make a move that helps us understand our next move. Over the course of time, of course we have a very important end result of winning the game, winning the market, or whatever, but through that, many times, multistep process, that aligns a roadmap we can go and bite size build features and product, and very importantly, hire a team that is open to a little bit of wiggle.

We’re not going to get it right every time. In fact, more times than not, we’re going to get it wrong. Making sure we don’t go too far down any particular path without playing that chess game with our roadmap.

The balance as a founder, particularly one that comes from a product side, is everything is possible, and you want to build so many things. In fact, with RealSavvy, my cofounder is the best designer I’ve ever known, so I have this huge asset in him to actually make it beautiful from the start instead of go the ugly MVP route. It requires a lot of discipline, more than, honestly, any other company I’ve done. In this case, we want to build beautiful products, but we have to be very disciplined to not get too far over our skis.

William Griggs: Got you. So you’re starting with kind of the start small, get that first group of, say, 100 people really loving you. That way you’re de-risking the approach you’re taking. You’re able to have one-on-one conversations, like you said earlier, to kind of understand are you making the right decisions? Are you going down the right path? What are some of those conversations look like as far as deciding should you build A, or should you build B?

Rick Orr: You have to have an endgame in mind. Building fun futures is fun, obviously. One day with some level of exit, I just hope to build really fun products, and if they make money, great. Today, we’re in the business of making money, so we have to make sure that whatever we’re building has an ROI component to it, as trite as that sounds.

The way we approach products within RealSavvy is, again, we try to build just enough with just the base-level functionality so we can sit with our end customer, and learn what it is they like, what it is they dislike.

We have this model with RealSavvy where we’re wanting an army of 2 million agents to invite all their clients, and that’s a growth strategy that’s sort of bottom up instead of what has been more typical in the world of more social related platforms of sort of top down, search related, viral growth, etc.

We have a very intentional path, so it makes it easy for us to center that if we aren’t doing something that drives an agent to invite a client, then we’re doing the wrong thing. As a theme, as a company, we just set a very base level vision. If we’re building something today that makes an agent go to this platform every single day, then we’re doing the right thing. If we’re not, challenge me. Challenge Clay, my cofounder. That’s kind of where the cultural bit comes in; to make sure we’re all self-accountable because, again, building fun things is fun. It’s just not always the right thing to do.

William Griggs: Got you. So you have this vision. You’re taking it apart bit by bit. You’re thinking through the bowling pin strategy. What’s most essential? Where are you going to knock it down? Then you’re thinking through, specifically, the overarching goals that are going to help you knock down that first row of pins, then get to that second row. As you’re building momentum to knock down the first row of pins, you’re still thinking long term.

You’re still thinking about what’s going to eventually make this company successful in the long run? Like you said, it’s kind of that sharing and growth strategy that’s going to make it essential, and you’re having those smaller one-on-one conversations to determine – do you have the smaller one-on-one conversations to determine what to build, or do you do it more on a does this make sense perspective?

Rick Orr: It began – I try at least every Wednesday. My personal regimen is every Wednesday; I try to have at least three meetings with either an agent or a broker. Those are our primary customer. We’re sort of a B2B2C play if you look at it in that regard.

Initially, I was just having conversations with agents, telling them what I viewed as the problem, and then trying to observe body language, just listen intently, and always have someone with me that would jot down the things I might not catch. In those moments, you really hear the true pain, and we found – and I had to be very open and honest with myself – a lot of what I thought was their problem wasn’t their problem.

We didn’t build anything until we started having those conversations. Then we actually used mostly paper tests. We’re starting to use more of the things like Marvel app right now where you just load images into what looks just like an iPhone app, or just like a web app. People can click around, see the flow, and give you feedback.

I would have pieces of paper, and people would say things. I would flip the paper over, and write down my notes, and go to the next one. I found that to be very effective.

I have since – the first startup when we got it acquired by Symantec, while a very big company, the product team had a really disciplined approach to picking the next feature, and they had very specific calendar problem they could only release once a year because of what had to go out to retail.

It really instilled in me, the product owner and manager, the discipline of what paper tests can do. It’s really fun when you come back to your team, and you’ve got this physical thing you can have them look at, and you can have everybody shut their laptops, and go through these pieces of paper together. Even people who don’t have a lot of contacts through the industry can start to feel the pain a bit of why that makes sense whereas just building code, and beautiful images on screens maybe doesn’t illustrate that.

William Griggs: Got you. As far as working with the team and thinking through things about what to build, how do you balance bug fixes versus optimizations versus new functionality? How do you think about that as kind of an early stage founder versus a little bit later on where you were with TabbedOut?

Rick Orr: Great. In fact, part and parcel to probably my current challenge/opportunity with this company, and related to TabbedOut, which had many more years of maturity before we had to make the shift, but at this stage, it balances. It’s exactly the word. I don’t know that I have it nailed. I don’t know that I can give the most sage wisdom on this. It’s something of a learning process, I think, for us all.

Quality is everything. People have a bad experience, even if the feature you think they’re going to love is three steps in, if they don’t get there, whether it’s marketing or quality, all is lost.

We’re at this important stage with RealSavvy with a very small team, and the housekeeping items are creeping in, and making very good cases to be prioritized even moneymaking features because we have to make sure that our first user experiences for that small group of people is great.

It’s, I’d say, an iterative process. I think the best way I’ve found it is that there’s a culture of the people that know where the bodies are buried, and those are typically the engineering team only, who are vocal. You give them a platform to where they’re comfortable no matter how assertive or Type A the founder is, which sometimes I’m probably accused of, and they can yell at me and tell me that if we don’t do this, all the things you want aren’t going to work.

I don’t know that there’s a precise software delivery process. I don’t know if there’s a tool that solves it more than hiring great people that will be very honest and vocal on what’s going to bog down the machine that the people looking just through the front of the windshield don’t realize. I don’t know if that purely answers the question, but that’s how we approach it on the day to day of a new stage startup.

For TabbedOut, we went through and kind of walked through the forest the first couple of years. We had a very difficult problem of integrating with all of these disseminate point of sales systems. As much as they’re lovely partners, most of the technology was written years ago and had to stay on those platforms because they had such a massive infrastructure of supported customers with names like TGI Fridays.

Not easy for that industry to evolve, which meant we had to – I don’t mean this exactly how it sounds, but devolve, to not use everything that’s the newest and greatest technology.

That meant that once we got quality right, we had to make sure we sustained that. a lot of the focus for a company like TabbedOut, we’ve got third-party dependencies, and it has to be maintenance mode because your people around you are making changes on their stack that impact your consumer experience.

We found the shift in TabbedOut and the companies now making a great shift into picking up some of the newest and greatest technologies from Bluetooth low energy and a host of other very cool things that you’ll see come out of the TabbedOut product team.

Very different stories. In today’s day with RealSavvy, we have to have a daily balance in conversation about what to fix and what to build, and I think companies that are six years old like TabbedOut go through more long phases of one or the other. Once one is established, particularly quality, then it gets really fun. You get to build products like what’s out there now. Or it recognizes that you bought a Miller Light, and you get $5.00 off your tab. People like that.

William Griggs: Yeah. Very cool. As far as transitioning from talking about the product strategy to talking about the product team, how do you think about building your product team, and who are the people that actually comprise the product team?

Rick Orr: In my experience, and one day as we grow with RealSavvy, I hope to achieve these structures. Right now I’m sort of dual purposing product and general management/leadership, etc., fundraising, business fulfilment, everything. Everybody wears tons of hats at this size.

What I think is the most effective product team – I think it’s different between verticals. If you’re on a consumer track, I think one of the most important roles and counterparts to a great product manager is a product marketing manager. I think they’re very distinctly different roles.

Microsoft always had that as kind of a joined role. I think that is reflective of more of the enterprise model. Where that can be the case, you don’t have as dynamic and changing a support, and consumer audience to address the new hot, squeaky wheel, which may not be the most important thing to fix like you might with the consumer side.

I think the best teams are really talented product management ownership and leadership, typically, with a counterpart and product marketing, and another individual that, frankly, is just smart. I’ve had the most success with people who hasn’t been one thing or the other before. Many times, like my first job, they come from a consulting background where you have to be very dynamic, and look at lots of different verticals, and lots of different markets.

I like that blend of someone who’s a little bit more of a greenhorn that can learn from more senior product marketing and product management team on the definition the valuation of the marketplace and the overall strategy.

Then I think it comes down to your counterparts within the organization from a cross-functional perspective. I was a crappy developer early in my career, so I’ve always been able to at least hold a conversation with engineers that run laps around me on my best day, but it gives me a little bit of street cred with the teams that I try to stay up on the latest technologies.

I try to understand what is the trends in big companies that are scaling so that when they come with a request – like TabbedOut, for instances, moved a portion of its stack to Scala, and our head of engineering and I had a conversation where he explained all the benefits and all it could do.

While I didn’t understand it purely, I had a moment to kind of get an understanding that big companies, of course, are using it. I think that kind of helped culturally between sort of engineering, and product, and the different teams to adopt new technology, understand that our roadmap is going to be impacted, but it is going to have long-term benefits. I think there’s kind of a core product team, and then I think the real success of product is the inter-relational side of cross product.

William Griggs: How have you seen kind of the responsibilities been divided across product managers in some of the bigger companies you’ve worked with.

Rick Orr: Symantec being the largest, we had a very distinct roles and responsibilities with the Venn diagram literally between the product marketing teams, and the product management teams, and the engineering team’s kind of coming together. In that case, product management really focused on, and what I’ve seen in bigger companies, focused on most of the strategy.

What are the competitors doing? What is the landscape shift? What is the new hot technology that we could pull in to our stack to go and get a decided advantage, and what are the parody features we just can’t look past, and if we don’t have them, we’re going to lose market share?

That fed in well on the market share side, so the product marketing team who better assessed the competitive landscape from how people are messaging, and how you kind of work backwards into what features need to be built based on what consumers are saying, and very analytic and very quantitative measure from what’s going on in the field directly from customers, and then of course the engineering team being the constituent that without their support, it’s all for naught.

William Griggs: Got you on that. As far as how it’s structured at TabbedOut, do you mind talking a little bit about that?

Rick Orr: TabbedOut, we always had a product role. We had this interesting model. We still have this interesting model of marketing to a number of audiences. You market to the owner of a bar or restaurant that this is going to help their bottom line. You market to the management, and very importantly, the bartender and server that this is going to increase your tips. Still today, the company has something like 28 percent average tip, but it takes a little bit of evangelism to convince them of that.

Then you have the all-important consumer who needs to know it’s available, simply know how it works, and just have a great experience. It had to be a tag team effort. Sales really had to learn how to be part product, part marketing. What product’s role and marketing’s role in that was to make sure they had great materials and could crisply and concisely convey – in ’09 we didn’t have any competition. Since, there’s been something like 15 companies that have come and gone since TabbedOut began in that space. Much applause to the team for longevity.

Over that period, we’ve had to evolve the messages to the owners and staff, and that’s been a very joint effort between the infield sales team, much like what Yelp would look like, or an Open Table product back at HQ, and marketing at HQ to put together the packet that would make sense.

Then, of course, on the buildout, make sure that as those people come back with, “Hey, what you thought was going to work didn’t work at all. We need to build this,” or “This feature will help us sell.” All the usual suspects. That’s what it looked like more at TabbedOut.

Internally, the very analytics focused partnership between marketing and product, and just general senior leadership to understand what’s going on in the space, and try to make sure that the consumer experience was such that it was an absolute that you would never want to use your piece of plastic again. That went all the way down to buildout, to messaging, to all the things you would expect.

The roles of product manager are a very separate group but very tightly bound group of marketing, and then a massive group of infield people who were the tentacles into the marketplace to get the information we needed. There are a million restaurants in the U.S., so you need a big team around you to get the right information back to make decisions.

William Griggs: Got you. As far as getting the product actually built, you need to work with the engineering department. Do you see any best practices, or do you have any advice for founders as they’re managing a little bit of a product department and an engineering department, and thinking through how they best work together?

Rick Orr: One thing that I’ve found is never put together a roadmap that doesn’t have an appropriate percentage for that phase of the company that is in a bucket called housekeeping. It’s always the case that the engineers know more about what’s going to creep up as you scale than anyone else.

Nothing, I think, erodes the relationship between engineering and product more than continuing to just push for what you can see immediately in front of the windshield, and not pay attention to the fact that going 90 with a pothole ahead is going to break some stuff.

Giving the team the built-in time on the roadmap, and then communicating as their advocate to whomever leadership is, or if you are leadership, being introspective in that regard, that that time is just as important as this big feature.

The other is a little bit on the topic, as I mentioned before, of trying to understand when there’s new shifts in technology, trying your best as a product leader to stay abreast.

One of the best product managers I ever worked with was Oliver Schmelzle. He unfortunately passed, but we were together at Whole Security, and he was a wonderful German guy. I learned a lot from him, and his diligence in the marketplace was unsurpassed. He would spend copious hours outside of regular hours trying to understand shifts in the marketplace.

I think that gives the street cred you need to work with an engineering team. They’re confident that you do have an understanding, just like they do from what they read on Stack, or whatever. I think the real successful teams have a really tight bond between engineering and product.

There are always going to be debates on timelines, and no one likes date-driven development, but the business has to work like that most of the time, and the product management is typically the messenger.

In the spirit of don’t shoot the messenger, I would encourage engineering teams that are listening to remember that. The product is intended to take from across functional groups – sales, marketing, etc. in the business at large, and try and negotiate, and horse trade to get the best product out that a small team, or even a large team, can fulfill. That’s my experience with it.

William Griggs: How do you advise the product managers listening or the CEOs acting as product managers, how do you advise them to incorporate their development team into the process so the development team feels as though they have ownership over the product as well?

Rick Orr: There’s as much you don’t need to communicate as that you do if you’re serving that role. At least, that’s my experience. Those of us who have the product lean as also CEOs and founders, you know what you want to go build so clearly, but you can’t. In some cases, you’re still trying to figure out if you build it, how do you monetize XYZ?

Where I’ve made mistakes is over communication. If I include the engineering team into things that are too far looking, it comes off as distracted, and that goes back full circle to the beginning of the conversation. It feels as though you’re trying to blow the ocean, and that’s sort of a paralyzing event in a company, especially a small company. It’s like we’ll never get there. That’s too much.

You know that you’re seeing at as the chess game, but you have to be very careful about information flow or the setting of information so that it’s not construed as, “Rick is just going to have us build this. Why would we worry too much about whatever we’re worried about because it’s going to change?” It’s always going to change, but there has to be a cadence to it.

My best advice is take a lobotomy pill on what you want to go do while you’re in certain settings, but make available – what we try to do – it’s not a very formalized thing yet, but we’re trying to formalize it.

Every couple of Fridays, have a penalty free zone to just talk. Talk about where we want to take this thing. talk about what I kind of see is coming down the road, or my cofounder sees coming down the road, or give a forum for the newest developer that has played with the app that thinks if we went down a certain path, it would help us a great deal. Give them that forum.

Then remind everyone that on Monday, we’re back to what we use as Trello right now, just to sort of manage a burn down. If it’s not on that list, it doesn’t make the cut. There’s nothing else to worry about there.

I think that’s the challenge. You have to be very careful with communication too much vision. You want to communicate it to the point that everyone sees the vision that you’re going somewhere really big, but on the day to day, that can be very paralyzing if you’re not careful.

William Griggs: That’s a good piece of advice. You can definitely see some people getting motivated by that long, big goal vision, and other people kind of being demoralized or at least frustrated, and thinking, “What is this little piece that I’m working on now have to do with that? We’ll never get there,” and that type of stuff.

One concept you touched on was the burn down. Can you dig into that a little bit more?

Rick Orr: Sure. It’s as old as any methodology, I guess. Trello, I think, is just a great communication platform. In fact, if you look at the RealSavvy platform, you’ll notice some similarities of how we think agents and clients should sort of collaborate in one centralized place.

Trello and others – there’s many like it, but it just happens to be very cost-effective for a lean startup, bootstrapping startup, seed stage startup – what we do is we try to break off. We have kind of a roadmap board that has sort of columns of themes that impact and benefit agents, themes of housekeeping items, themes of ways we make money, themes of things that are really important for consumer adoption and marketing scale, and they’re all stack ranked in their individual columns.

We use loosely a kitchen analogy, but that’s the prep area. Then nothing goes to the grill, which are individual boards that are more sort of assigned to typically an individual today. Eventually it will be more of a team, but we’ve got a board for what we’re doing with the next web release, what we’re doing with the next mobile release, what we’re doing for call to action throughout both platforms. It’s more of a marketing burn down.

My job, and eventually as we bring in a product team, a grander product team, their job is to make sure that the priority stack meets with the business’s goals for the next 30, 60, 90 days, and really no further out.

From a burn down perspective, you start with this beautiful, very clean slate of a dozen to 20 bite-size items. None of them can take more than – we try to keep it to less than two days. I would typically say it should be less than one day. In early stage companies, you don’t yet know how to size everything, so we kind of give a little bit of extra buffer there. It’s two-day bite-sized things that the engineering team and marketing team can fulfill.

They just move left to right. We sort of create this board of to do, doing, done, and then verified. As a team, we all come in and move things from done to verified based on our knowledge of the system as sort of a joint QA effort. That’s how we work burn down. We try to keep each board to about two weeks, much to the agile and scrum type of methodologies.

I’d love to say that we have some perfect methodology, and we don’t. We always strive. It’s more important in my advice to people that get a little too caught up in that that tools are tools. They’re just tools. Methodologies are methodologies. Your team may or may not be the best fit for one or the other. Culture is what lends to great product development and great predictability of the business.

If people are accountable, and honest, and transparent, and vocal, it trumps anything in any book you can read. I use Lean and all these things as great kind of North Star guides for us, but I’d be lying if I said we fall anything precisely because every release is a little bit different. Every – particularly at this stage of a company – decision is only 70 percent right, at best.

William Griggs: Right. So as far as transitioning, you talked a little bit about the different buckets. As far as transition from that product idea that is high priority based on your business goals for the next 30, 60, 90 days, what does the handoff look like? What are you providing the development team so they can get to work?

Rick Orr: At a larger company – and this is where it becomes a challenge for a dual role, PM, founder, and fundraiser, and all the other things that you get with this stage of company – a larger team –

I’m a very big believer that you over define, and you under design until you get a really good scope from the engineering team. That’s done through a scrub. The way I learned it at Symantec and other companies, and that I’ve had success with, is you go through the priority stack of what the business needs. You sort of get alignment with sales and marketing. “If I give you this, are you going to be happy? Is this going to help you achieve your goals?” If you’re the CEO, you’re asking yourself, “Is this going to help me achieve our fundraising goals?”

Then you parse that out into two-week chunks to where each individual card on the burn down has sufficient definition. In a company where you have a team of a dozen or so, maybe 10 or so engineers, you really have to assume that no one knows a thing that’s ever been built, and no one knows a thing – even though they do. That’s the level of definition and detail you have to go into.

We’re at a stage of we all sit in an open format together, technically and literally around one big table. I try to not over define right now, which I think we have to make an evolution as a company. That’s something that’s my keeping me up at night moment and recognition. We’ve had some things come through that should have been better designed. That’s on me.

I think it’s a balance. You can spend all day writing specs, and that doesn’t necessarily help the business as much as hiring a team that will ask a question like, “What did you mean by this?” Trello gives a great format for that. Again, a tool is a tool, but it gives an immediate notification to me on my phone. Like most of us, sadly, that’s where we live. I can slide straight in and answer a question to clarify. That works well for us.

Down the road, larger, more mature companies, bigger teams, over define, under design until you have a moment to sit down with the team, and really scrub through each individual item to make sure people understand it.

Then you can pay for a designer, or we’re very fortunate to have an in-house designer who can take it and make it the thing it needs to be, which is the user experience part, which is so critical.

William Griggs: Got you. So you’re talking about as the company gets more mature, you’re starting to define these things. You say over define. You’re starting to list out all the different details. We’ll dig in a little bit to that. Then you’re going to get it designed. Then you’re working with the engineering team to actually implement it. Before you get a design, you’re working with the engineering team to make sure that it’s fully understood?

Rick Orr: Fully understood. Right. You can have the most beautiful design and user experience strategy. If you learn after all that investment that everyone is very excited about pretty pictures, that there’s a piece of the platform that has a predecessor that has not yet been built, and someone thought it was going to have been built but it’s dragging on its individual schedule, it’s very chaotic.

Then it starts to sound like scope creep. It starts to sound like all the things that can plague an organization, which had no bad intentions. If you don’t have that moment to scrub with people that are actually going to be accountable for a timeline for building it, there’s no real reason to go too deep in design, or you’ll get burned.

William Griggs: Got you. As far as over defining, can you tell us a little bit about what that looks like?

Rick Orr: Again, very honestly, we’re not at the over defining stage, as much as I wish we were here at this stage with RealSavvy. We’re trying to get there, but I think TabbedOut was a good example, and Symantec and other companies.

What we tried to do was go and give a user account, kind of your typical epic stories, etc. What I’ve done in smaller companies, in fact much credit to our cofounder Matt Swezey who did come across a great article that described what if when you’re really comfortable with what you want as a business, you wrote a press release, and that was part of the scrubbing process?

If everyone believes that press release is true, then let’s go forth with extreme vigor. If there’s any issue, it should come out because we’re going to announce this to the world. Even on the internal housekeeping releases among your team, this gives an opportunity for even the newest developer to be part of a press release with this great feature they built that maybe no one will ever see, but it’s really important to our internal team and our schedule.

That’s one of the things we’ve employed that I’m really liking a lot because it puts accountability on marketing. They’re messaging the right things. Conversely, it puts accountability on product development and QA, etc. teams, business building teams to make sure that’s what’s in there is accurate and can be delivered on the market side.

Stories, press releases are good tools. Telling it in the first person. We did that a lot at the early stages of RealSavvy. “I’m an agent. I’m frustrated in this, etc.” Here’s the problem. Then a resulting story of how something solves that particular problem in words. Then you flesh out the functional requirements, and the marketing support, and the cross functional requirements to make that real. That’s what you scrub with paint.

William Griggs: Got you. Do you actually get all the way to wireframes, or is that too early for wireframes?

Rick Orr: I’m a big fan of wireframes. A picture is worth a thousand words. What I would typically do with wireframes around a story is just the ugliest wires you could ever do. I’ve tried Balsamiq. There are lots of great tools. I find that through too many years, and product and sales, and pitch decks that PowerPoint is my fallback, which drives my team crazy that I create PDFs at the end of the day.

My cofounder being a designer actually helps. I can do something ugly in PowerPoint that he can put in a platform like Sketch, which I highly recommend, by the way, or Photoshop to make it a little bit more – as quickly as I could in PowerPoint – a little bit better communicating to the team what it is we’re trying to accomplish.

William Griggs: Got you. As you’re sitting in those meetings looking at the different things in the columns that you talked about, how are those conversations handled as you try to prioritize what’s being built and what’s not? Do you as the CEO or the head of product get the final say, or is it a different approach?

Rick Orr: I try my best to make it more of a joint voting democratic thing. The reality with our business is if it’s an agent feature, a lot of times I become the customer, which is both good and bad because I’m still going to be wrong enough times to where I’d rather the team had some gym of information that came through either more of a quantitative measure of our analytics, or direct conversations with the customer.

On a small team, someone has to be the final say, and of course my cofounders and I try to stay closely aligned. If it’s a usability feature, I defer it to my cofounder. I think he’s a bit of a savant when it comes to understanding the human elements of things. Anything that impacts our scale, my cofounder Matt is our head of engineering. He understands where the bodies are buried there. If it impacts the business, of course, our head of marketing and myself stay very closely aligned on those things.

It depends, but big decisions, strictly decisions that would impact the grand direction of the company, I do chime in on as the final say, but I think the best companies have an environment to where the very new employee can be extremely vocal and not a big scared to object even to CEOs and founders.

I’m very proud. I think all the companies I’ve been involved with, TabbedOut and RealSavvy, we’ve had that kind of culture of people sometimes being brutally honest. Sometimes it hurts to be wrong, but being wrong and moving the company in the right direction ultimately feels really good.

William Griggs: Got you. So as we start to wrap up, a couple more questions. I see that you advise several different tech startups here in Austin on the product front. What are some of the things you typically work with startups on?

Rick Orr: Because it’s a little bit older – I guess I’m a little bit older, but I had the good fortune of working with that gentleman I mentioned before, John Metcalf. I just think there’s a lot of great, proven components and things that aren’t the typical hot books or methodologies.

I try to get founders first to sort of think about their market, like the bowling pin strategy. I try to work with founders a lot less on the product side and more on the business side of things I’ve learned that I’ve, frankly, done wrong, whether it’s related to strategy around fundraising, or what you communicate to your team and when, and how to disseminate information.

Scars are good. I wish people went back. I’ve had a great number of people reach out and help me with some of the things I could have never known if I hadn’t just made the mistake myself. Sometimes I still made the mistake myself, but I more quickly recognized it when I remembered a conversation. That’s what I try to do with people I advise. There are some great CEOs and founders that I get to be a part of, Formasible and Favor, etc. They teach me as much as I teach them.

Long and short of it, I try to help people with more of what not to do than to tell people what to do. I don’t know that I’m purely qualified in the latter as much as I am the former.

On the product side, all of the companies I’m involved with, the CEOs are very much product oriented people. I think the key thing there is you have to retain that passion. I don’t know that you can do it outside of that role. I think a product oriented CEO yields some of the most important companies, particularly in marketplace, and I enjoy working with companies that have that type of leadership and founding teams.

William Griggs: Very cool. We’ve given the audience a great jumping off point, a great foundation to help them build out their product team, and help them think through their product strategy. Are there any additional resources, blog posts, bloggers, books, etc. that you would recommend people kind of dig into to help strengthen that foundation so they can not spread themselves too thin, and they can make sure they increase their likelihood of success?

Rick Orr: I highly recommend the series of videos that Sam Altman, and Paul Graham, and a host of others did out of Stanford. It’s easy to find online. Sam Altman, of course, is the President of Y Combinator now.

Then as far as books, I think two. I have two book recommendations. One comes from a great guy here in town named Derek Keller, but he recommended Losing My Virginity by Richard Branson. You’ve got to have some moxy to be a startup founder or CEO, and to shake things up in a marketplace from a product perspective, you need the same. I don’t know of many people who are a better illustrator of that than Richard Branson. It’s a fun read. It’s not your typical business book. I definitely recommend that.

Because he starts every chapter with a rap lyric, I think Ben Horowitz’s The Hard Thing About Hard Things is another must read. Even though some of the discussions are more late stage, like Opsware and LoudCloud, and all the things they did there in Netscape, he puts it down to paper really well from the chair of someone who started something from scratch.

Those would be my two favorite books to recommend.

William Griggs: Very cool. I’ll put those links in the show notes below the video. Rick, thanks for joining us today.

Rick Orr: Thank you, William, for having me.