Welcome to the first post in our "Friends Who Tech" series! A series of casual interviews with founders, engineers, designers, managers and more from around the world. Our goal is to highlight individuals who you may not have heard of. To share their stories, struggles, journeys, and triumphs. We hope to highlight the rich diversity of folks building software and hardware products.
The format is rather simple. In short, we schedule a simple ~30-minute Daily.co video call with each individual. We then record the call using Daily.co and transcribe it with [Rev.com](https://rev.com) — each transcription is edited, to make for a better reading experience. Pending approval from the interviewee we then post our conversation here, on our blog.
In our first chat, I (Stephen Meszaros, Design Lead for Daily.co) had the chance to talk with Rob Sicat, Product Strategy & Design lead for [Koan](https://www.koan.co/). Rob is based in Portland, Oregon and is working with the rest of his team to help improve the jobs of managers through their software.
If you are interested in taking part, please don't hesitate to [DM me on Twitter](https://twitter.com/stephenmeszaros) or [email me](mailto:firstname.lastname@example.org) directly. I'd love to chat!
**Stephen: I’m here with Rob Sicat, Products Strategy & Design for Koan. Rob, thanks for taking the time to chat with me today. I’d love for you to introduce yourself.**
**Rob:** Sure. Yeah, so like you said, my name is Rob. I essentially lead Product and Design at Koan. We're an early stage startup that is focused on making managers better. I think one of our core beliefs is that there's a lot of managers out there but most of them are bad, and that's totally okay because it's really hard to be a good manager. So we're trying to build tools that essentially nudge people into better behaviors that yield amazing results.
We've been doing it for about two and a half years, and along this journey we're also having this meta conversation of how do we build a company in Portland, Oregon, and in Palo Alto that we want to wake up to, every day, and be excited about.
**Stephen: That's awesome. Thanks for the background. How did you come to Koan? What drew you to this team and project?**
**Rob:** I'd like to think that it was a methodical decision to come to Koan, but really we had moved to Connecticut — my wife and I, and our kids — and I was commuting to New York City every day. It was, two hours one way door-to-door. I did that for about four years, and although it was nice because I got to get a lot of reading done and a lot of personal growth, I just kept thinking in my head that that time could be better spent with my wife and kids. That was kind of the forcing function.
So, on a bit of a whim, we said, "What about Portland?” and I think, the next day, I looked up early stage startups [in Portland] because that's what I'm passionate about. I wanted to have more control over design, product, and input.
I found Koan, on AngelList, and this might sound, I don't want to say shallow, but the logo looked better than all of the others. I think I was biased into thinking, at least this company probably cares about design. I did some research on the founders, and found them to have a pretty successful track record, and I thought it would be a good bet to place if we were gonna move our family and kids all the way out to Portland.
I just sent an email to Matt, who was the CEO, and I just said, "Here's my portfolio. I'm interested in possibly moving to Portland. If you think my skills align with what you're looking for, please reach out." And I think he emailed five minutes later, we had a video interview, and a few weeks later I flew out to Portland for a formal interview. A month or two after that I ended up accepting the job and moving to Portland.
**Stephen: That's awesome! There’s a lot to unpack there. I've heard great things about Portland. To that topic, was Portland interesting for the work/life balance, and how do you manage that balance as a lead designer for a young startup?**
**Rob:** That's always been, not a struggle, but just a constraint. At early stage startups, everyone has their own opinions, some people say, you need to be working 90-hours a week, where others say, no, you can work 40-hours a week. So, I think it depends on the maturity of the person and the company. But that was one of the things that drew me to work for Koan, they cared about life outside of it [Koan].
In Portland, I've cut the commute down. If I ride my bike in, it's 30 minutes. If I take a Lyft home, I’m home in 15. There's really nothing that beats that. The other thing [about Portland] is just the access to trails, the ocean, mountains. That is just something that you can't really measure in dollars — just being able to take trips and access nature. I think all that's definitely a plus, but ultimately it comes down to what your company cares about. For instance, one thing that we knew going into Koan was that our founders were going to be remote, somewhat. We had to build a team that was more senior, that was more self-managed, and that's how we've run things.
We believe in having a life outside of work. We believe in working smarter, and not longer. It's having those beliefs just enables us to set the tone for the rest of the team—that you need to work, to get not as much done as possible, but as much valuable stuff done within reason.
**Rob:** In short, it really is on the individual and the team to support one another and trust one another. That you're getting the most valuable things done, and the most critical things done, for the customer and business.
**Stephen: That resonates with me as well. Finding a team that is all aligned with the concept of work/life balance and the concept of trust is critical for remote culture. I'm imagining it probably ties into the roots of what you guys are building at Koan as well.**
**Rob:** Definitely. It's one of the most difficult challenges when you're building software…when you introduce people into the equation. Surprisingly, it gets exponentially tougher to build a really great product. We've gone through many iterations of what Koan is. But really our north star is that, we're trying to build tools for managers to better do their jobs. You look at all the tools that the industry offers, there’s, Sales Force, you have GitHub for engineers, there’s a slew of design tools. I think you and I both know, there are so many design tools nowadays—it’s an exciting time to be a designer. But for managers, there's not really one tool—or many tools—that people call out and say, "This actually helped me be a better leader and manager."
**Stephen: That’s a very real challenge, and I imagine that dog-fooding your own product gives you a lot of information. Outside of dog-fooding Koan, what's your approach to product strategy? Are you talking with users a lot or prototyping? Could you maybe speak a little bit to how you approach design?**
**Rob:** I would like to make a statement where it's just like, "We follow this exact process," where we use the double diamond or IDEO process to understand the problem. I think everyone does a form of discovery definition, prototyping, getting feedback, where you actually circle back into the process. It differs with your company and the problem you're solving. We try to do that as much as possible but real life gets in the way.
So right now we're at a phase where we have enough signups that we get enough feedback through tools like Intercom. In the beginning our process was very discovery focused, we did a lot of prototyping because we weren't sure what was the right thing to build. Now, we definitely still have a mix of that, but it's all about iterating on the product, trying to solve new customer problems, trying to build new features, and new products.
So two examples. One, would be a new feature that we're trying to build out. I’ll get together with sales and our customer success teams to try and figure out what the most valuable problems we can solve are; we go broad on that, and write up almost like a press release or like a Bezos-esque kind of pitch on what we want to solve so that we can get everyone on the same page. Once we have a good understanding of our problem [and we are aligned], then we can explore the solution.
What we try to champion is, code wins. So getting features shipped to customers is much more valuable than getting it to them later. We ship to learn. We have a philosophy of getting what we’re building into the user's hands.
[Second], for more vision type stuff, we will make prototypes in Marvel, in InVision. Sometimes in Framer. But really, it depends on the the type of feedback I'm looking for. So for that high level stuff, we'll use more interactive prototypes like Marvel or InVision.
**Stephen: Yep. That totally I think makes sense. To that point it sounds like you have a pretty good cadence with your engineering team and are working really closely with them. How did you form that collaborative environment with your engineers?**
**Rob:** Yeah, it definitely took some time to get that relationship going, and I think a lot of it is just having engineers that are passionate about building product and about solving problems. Getting on the same page and not having a myopic view like, "Hey, can you move this ten pixels, and can you actually change this icon?" But instead involving them early in the process. I think that's really what, just from past experience, has helped build better relationships with engineers. I don't have all the answers. I want to flip a switch and be in collaborative mode. This isn’t, I'm consulting you. This is, I want to explore this problem together, from the technical side, from the design side. I want to work together as one team to see what we can do to get value to the customer this week.
I think when you frame it that way, that empowers people and gets them excited. That's what's really helped my relationship with engineers because I am the lone designer, and it does get lonely. So I think what I end up doing is just enlisting other people to join the cause.
**Stephen: I think you're right, it also brings a new feeling to your role and makes you feel more, supported, or involved, perhaps. I'm also working as the lone designer but with a very collaborative team it makes my life more interesting at the end of the day. I feel like I'm growing both as a designer and individual in terms of how I collaborate with people outside of the design world.**
**Rob:** Are you the only designer right now at Daily?
**Stephen: Yeah, just me. But, I guess that's kind of another question. As the only designer you're wearing a product hat, you're also doing visual design, you're involved in implementation, to a large degree. How do you find balance between all of these things, and do you enjoy that or dislike it?**
**Rob:** I don't know if it's generally a rule for a lot of creative people, but I'm attracted to being able to contribute to many different things.
I think it's a challenge I face every day where I come to my desk, I open up Notion, and I have this Eisenhower matrix of, what’s the one thing that I can do that will make an impact, and how do I make sure I do that. That is the hardest thing, balancing all these things you want to be involved in. I think, for being a person who tries to be accountable, it's about having clear expectations of what is the most important thing that I can get done. My typical day will consist of a check-in with a team, to determine what we want to get done today. But what will really happens is the CEO will ask for help with a pitch desk, and then someone will drag me into something else. Now that I have all these additional inputs, it becomes about ranking them and communicating that with the team.
I think that's the exciting thing about working at an early stage startup but also the hardest thing.
**Stephen: Certainly. You were talking about juggling many different hats. It is a blessing and a curse in many ways. It’s nice to have control over the 10,000ft view of a startup, from a design or product perspective, but at the same time it involves a lot of project management. How do you guys come up with the hierarchy of what's most important to be working on as a team?**
**Rob:** That's a great question. A lot of times we have a de facto company meeting where we try to be in person once a week. We try to include everyone, from engineering, product, sales, customer success. Yet, really what trumps everything is our goal setting process. That along with our roadmap. We have a pretty extensive OKR process at the start of every quarter where everyone pitches their needs: engineering, customer needs, product needs…a lot of those overlap.
At the end of that meeting we have some high level objectives that everyone can align on. That provides the guiding light for what we're trying to get done. So when we battle the day-to-day, we can use that as a decision framework. Does this help us reach our goals? Do we need this to survive? Is this a decision that's gonna kill us?
We're flexible with it too, as new information comes in, but we use it as a guiding light for product decisions, for customer decisions, for sales decisions.
**Stephen: I've heard a theme with your workflow, with users and also yourselves. It sounds like you’re saying that different verticals come together to plan for a quarter and users give you feedback along the way. It comes down to looking for patterns, and letting those patterns dictate what you work on. I've seen the same in our work for Daily.co. We let a pattern materialize and a lot of the times that gives us a guiding light as to what is most important.**
**Rob:** Yeah, and I think too, that as a company building software for managers it is important to have a clear understanding of what your mission is. What the vision is, what do we care about, what do our customers need. Having those kind of principles is so important to help that decision making process because when you don't have that then you're kind of stuck in a situation where you question who you are building for?
I forget who said this, but at an early stage company, saying yes to different target users is the death of a startup when you have to serve the needs of two different customers.
We've gotten a lot better at that, and a lot of it has just been a learning process.
**Stephen: That really is true. One of the last questions for you, that is top of mind, is what is it like working with your founders that are actually off site? It sounds like most of the team is really in Portland, how do you guys kind of manage that?**
**Rob:** Our culture's interesting where our founders are based in San Francisco — and Palo Alto — and commute to Portland every week…for the most part. That decision was made early on just based off of the talent pool that they believed was in Portland. So we thought it was better to build our headquarters in Portland with plans to expand.
What that really meant was having a team that's more self-managed, that's more senior, that's able to juggle multiple hats and make decisions about what’s important, on the fly.
That really only works when you have clear definition of what success is and what the expectations are. Some of that is just about having a principle of over-communication. That's something that modern tools, like Slack, Figma, JIRA and GitHub, allows us to have. But it also means using Daily.co and having in person connections with people — being able to sit down and talk for 30-45 minutes.
I would like to say it gets easier with time, but much like anything you want to get good at, you have to constantly practice it, not just do it, but actually know what you want to get out of it.
Knowing that our founders were remote, we had to devise and innovate ways to have more transparency around decision making, around pitching new ideas, around essentially getting everyone onboard. And so, we're still trying to figure that out and navigate that process. Over the last two and a half years all the new modern tools that are cropping up, with the likes of Daily.co, that focus on how you communicate has really helped us.
**Stephen: That's awesome. It's interesting. Something about being remote and being thrown into it really forces you to make decisions.**
**Rob:** Yeah. I think that's great, even for distributed teams or co-located teams, that's what great management can unlock. Because you don't want to be a chokehold on decision making. At any company, whether you're 10 or 10,000, decisions are made. People are working on things. And if you don't set that high level of, this is what I want you to get done and this is what success is, you're gonna work on the wrong thing. That just causes these cascading effects of, "Oh, I thought you wanted me to work on this thing.” That's where the stress comes in, and that's where you have to pull an all nighter. So coming back to what works for us is spending dedicated time on what's most important. Whatever works for you, but you need something to kind of guide your team.
**Stephen: So my last question for you is if you were to give just some brief advice to someone that's looking to work as the only designer for a startup, what might that be?**
**Rob:** Oh, that's a good question. It's a little bit different than starting out in design. I would say to someone that is starting at an early stage startup, to show conviction and confidence in your decisions. I found this very difficult early on. I’d do the research. I knew more about the problem than anyone else, but when it came time to presenting my idea to engineering, or marketing, and encountering a little bit of pushback — which is totally fine — I would shrink down and be like, "Wait, maybe they're right, and I'm wrong." But really they're just opinions. So just have confidence in yourself. Really think through, and practice how you present a design.
My own personal pattern for an important meeting used to be to research what all my design heroes were doing, but really, I shouldn’t have done that. I should have been simplifying things. I'd also recommend simplifying your ideas and problems so that people can better understand what you're saying.
If you do the hard work, if you're the expert, if you over-communicate and simplify your messages people will really grasp the core of what you're presenting.
**Stephen: That's definitely great advice. I think you hit the nail on the head that communicating, and continuing to communicate, and being the voice of design and product is why you are there in the first place.**
Rob, thanks so much for taking the time. I really appreciate you sitting down and talking with me about this stuff.
**Rob:** Thank you so much. This was great.
<iframe src="https://player.vimeo.com/video/334189629" width="100%" height="480" frameborder="0" allow="autoplay; fullscreen" allowfullscreen></iframe>