Back to all posts Back

The Product Shop – Episode 1: Founder Stories


Hey everyone and welcome to the first episode of The Product Shop: A show where we talk with product leaders about their story when it comes to building great products brought to you by Taplytics, a feature management, and A/B testing platform. 

My name is Michael Nguyen, I’m a growth marketer here at Taplytics and my name is Kate MacFarlane, customer success at Taplytics and we’re your hosts for today’s show. We’re starting this podcast because we’re in a unique position where we’re working with some of the most interesting companies globally to help with their product strategy through feature management and a/b testing so we wanted to share some of the learnings from working with these companies to shed some light on what goes on behind the scenes when it comes to building great products. 

For our first episode, we’re joined by Cobi Druxerman, Co-Founder & Head of Product at Taplytics as we reflect on his journey through YCombinator, his experience of growing a Toronto-based B2B SaaS company with 3 other co-founders, and understanding how he thinks about product strategy and growth at Taplytics. Now, Cobi comes from a unique background of building apps with the other co-founders since their high school days, getting an MBA, opening up a grilled cheese business to now eventually building a Toronto-based SaaS company. So Cobi, thanks for joining Kate and I. To start off, why don’t you kind of give the audience a little bit of a quick summary about yourself.


My name is Cobi Druxerman. I’m head of product and engineering at Taplytics and one of the co-founders. To go really far back on the whole journey, the four co-founders of Taplytics actually all went to the same high school and I lived with our CEO and one of our co-founders Aaron in university. The first startup we started while I was in my last year of university as the typical thing that any 18-year-old does, is try to solve the problems that we have for ourselves, which are few and far between.

But we tried to create something that would help with finding a rental listing so we created this rental listing website. Didn’t know what we didn’t know. That went for about three years and failed in unspectacular fashion and from there in about 2011 or 2012 started up Taplytics just as four friends trying to do something interesting with apps and parlayed that into a platform for A/B testing and personalization, and went through the journey to where we are today.


So you guys failed at your first startup, started Taplytics because you noticed a gap while building apps and then you applied for YCombinator. Could you tell us more about YCombinator, that whole process and shed some light on that? 


We actually applied to YCombinator a few times. So Aaron and I applied to YCombinator with the rental listing startup idea. Got no interest from that.

Then when  Aaron and I started working with Jonathan and Andrew, our other co-founders we applied with an idea before Taplytics that we were just kind of toying around with where we got a follow-up question to our application, but still didn’t get in.  Then we started the idea for Taplytics,  just as one of the application cycles was happening.

So we applied with just an idea like literally, I think that week we had come up with the concept for Taplytics. Didn’t get in because it was just an idea, but we were committed to this one. So we really liked what we were working on, we knew that it was pretty early in the application cycle.

So we applied Aaron and I, at least for our fourth time to YC and got an interview and got in. YC itself was a very interesting experience. Mainly because I think most people think about YC as something that’s going to guide, shape and be very prescriptive to your business.

I think a lot of people think about accelerators as these places where they go to learn the curriculum of startups. YC is interesting in that it’s more like a PhD than it is like a high school program. So you think about a high school program it’s very specific of like, you’re going to take this class, you can do these things and it’s going to this way and the PhD, it’s more self-discovery with someone picking you along the way to do your thesis.

In that perspective, YC is all about coming to them with your specific problems, at your specific time. And they’re mainly going to talk to you about how you think about the problem, not how you solve the problem. So most of the answers that YC gives are the same all the time.

You come to them with a problem and they ask you, well, did you talk to your customers about it? You come to them with a problem. They’ll say, have you looked at your metrics?  It’s more about how to think your way through it.  They don’t know the answer for your business because they aren’t doing the business.

That was very interesting. So for the most part,  it was all about just sucking out all the value that you can as an individual, making sure that you are open and honest about your problems and leveraging their advice to tackle it. The other part that was very interesting is the dinners, because all it is, is group, office hours and dinners.

Obviously, that’s less of a thing now during the pandemic. But at the dinners, the important part is less the speeches just that happened or the presentations that happen and more the interaction you have with the other co-founders. So the important part about YC is that when you’re in it, you’re basically in it with a  few hundred people that are all really, really impressive in what they’ve done and generally all at sufficiently different stages of their startup that with a hundred or 200 startups in a batch when you go to dinner and you talk to someone,  the vast majority of people that you talk to, you just had a killer week, they just crushed it. And so without failure, you go and talk to each other about how you’re doing, and you will feel bad because you just talked to 10 people who just knocked it out of the park and while you may have been happy with your results that week, it probably wasn’t as impressive as someone else’s. So you’re really inspired to get back at it, you know, go back to the house that you guys are all working out of together and try as hard as you can to compete when you’re talking to people the next week. I would like to call it positive social shaming.


Wow, positive social shaming, that’s an interesting perspective but I guess when you’re in that type of environment, everyone is really comparing themselves to one another but at the same time, you’re also drawing inspiration and motivation so that’s pretty cool to see. Are there targets that are set by the mentors for each startup or is it merely setting your own targets?


It’s all about your own targets. So if you ever think about lean analytics or things like that, it’s all about finding the one metric that matters, and then focus on that. At any given point in time for a startup, there should be one specific metric that matters. It should be trying to grow that metric week over week.  So at the earliest stage, it could literally just be lines of code, cause you’re trying to get a product out into market.

If you wrote a hundred lines of code this week, how do you increase the number of lines of code you write next week? Once you have a product in market it’s, how do you get your initial sign-ups,?  If you got 10 sign-ups this last week, how do you increase that to 20, the next week? Then once you have enough signups, it’s like, okay, I’m starting to make money.

How do I increase the amount of revenue that I have this week to next week and that’s really what it comes down to? Then as your startup grows, obviously you go from having these company-wide metrics to departmental. But they aren’t, we’re gonna set those metrics for you. They don’t know your business so you have to figure out what makes sense for you. 


And were you testing what metrics you should focus on? 


For us, we went through that natural progression. When we first launched, it was all about signups. All about just people coming in, testing it out. So we launched in YC with a tech crunch and Product Hunt and all of these things. Although I guess Product Hunt was actually a few months after we were in YC. So leverage that a little bit later on, but at first it was all just about hey, we got a hundred signups this past week.

How do we get 110 the next week?  Then we graduated to how much people are using it. When we originally signed up with YC we have actually focused more on just the dynamic editing of a mobile app. So, how many things are people editing, how much are people interacting with the thing? And then as we moved into experimentation, how many experiments are people creating? It was pretty natural for us because we already had the product on the market. So it was just that progression and then to a certain degree yes, at some point when you’re like, okay, we’re pretty comfortable with how people are using it.

The only focus that really matters since we’re trying to be a SAS company is revenue. Then you throw out those other metrics. They’re great to get you to a point and then it’s how do I go from zero to $100 and one to a thousand then, a thousand to a hundred thousand.


Looking back at it, were there any metrics that you think you may have overlooked that would have helped you grow faster in that early stage through the program? 


Yeah. It’s a good question.  You can’t AB test the past so it’s hard to say if something would have been better. We actually held off on asking people for money for a really long time. It was definitely after YC. We were all about free signups, get as many people using it. I can’t remember how long after YC, but it was really about just usage for a really, really long time.

And I think you could always debate on whether or not you’re tracking the right thing there and how early are you going?  I believe that the concept of charging for things is a really important motivator in terms of understanding true value.

That’s one area that maybe I would’ve done something different, but it’s hard to say like we are where we are because of the history of what we did. But I do think that people react differently when you ask them for money. So getting to that point, as soon as possible in the process.

I think it inherently changes the decisions because someone is going to say yes or no differently if you ask them for money.  


Do you think any of those metrics would have helped you on demo day and what advice would you give to people in the program when they’re looking to prepare for the lead up to demo day?


I think YC talks about it the same way as they did when we talked about it. Demo day is that opportunity for you to really launch and it’s this idea of once you pull the trigger, and the bullet leaves the chamber, you can’t put it back in like the genie can’t come back in the bottle. You have that one opportunity, at least at that stage of the company, to do that. There are very few times in a startup’s life that are actually true.  Everyone’s worried about launching a new product and all of these things. Just because one person used a thing and maybe didn’t get the perfect experience you have many other opportunities to do that again and again. You have one opportunity to do your YC demo day. So the most important thing is to have good metrics at the time. We were actually good at the time we had some pretty solid metrics. I think we had a really good demo and I think we had a pretty honed message at the time.

So we had a good experience. But definitely, I think the advice that YC gives is not to do it until you’re ready. They allow founders or startups to actually skip their demo day and use the next one if they don’t feel like they’re ready and I think it’s good advice.

The concept of using that tool when it is right is important because it’s very much a fundraising activity and fundraising’s an interesting concept because it’s one time in a startup’s life where you are not actually creating value.

All you are doing is transferring value. So all the time, like say a four-person startup you’re working on fundraising.  If it’s just founders two, three, four, five people and you spend months fundraising because you didn’t have great metrics at the time. That is time that you’re wasting from creating value because all you’re trying to do is get money that’s going to transfer value over to you and then you can obviously do something with it.  So you’re better served by spending time on your startup, creating that value, creating the growth metrics, and then when you’re ready spending as little time as possible in that process of fundraising, and demo day is strictly about fundraising.


I like how you mention focusing on creating value rather than fundraising because I can see how founders looking to go into the program can get side-tracked by focusing on the fundraising aspect rather than building a product that solves a need but with that, you went into the program with 3 other co-founders, would you say that gave you a leg up compared to say other startups that had fewer co-founders or would you say it doesn’t make a big difference?


It can help or it can hurt. I think there are very few examples of companies like us where four founders are still involved almost 10 years into the game. Generally, I think that is because it’s just difficult. Like the whole concept of starting up stuff is difficult. It’s a lot of time, lot of effort, like a decade into it you put a lot of sweat into the whole process and people get tired and there’s obviously the potential for clashes over different things, whether it’s money or effort so the more founders you have there’s a greater chance for conflict. The other part definitely is depending on how you’re finding your founder group. Usually, it’s through your own social circles.  Usually, it’s someone that you have known for a long time, and because it’s someone you’ve known you generally have similar interests. 

So the usual case would be that you have three or four founders, you have three or four, very similar people. So a lot of companies will be like four engineers get together and start something up. In that case, someone’s gotta be the CEO. Someone’s gotta be the CTO. Someone’s gotta be the salesperson.

So you’re asking a bunch of people that never thought of themselves as, whatever they’re having to do as that thing and that can create tensions. For us, we were super lucky in that of the four founders, we have pretty different interests, so we could always do things differently from each other in terms of our roles and someone wouldn’t necessarily feel like they’re put out or had to do something that they were not passionate about.


Just from working with you guys for the past 3 years, you guys have a very unique dynamic where everyone kind of has their own role. You don’t really cross the line between each other all too often. 


I’m sure we cross over a bunch of times, but I think the fact that  I’m never going to be a CTO.  I don’t have the skillset for that. And Jonathan, our CTO, has no desire to be a salesperson because he’s an engineer through and through. As simple as that is, I do think that’s an important part of it.

If you take an engineer and you’re forcing that engineer, because they drew a short straw to be the person who’s going out for sales, it takes a very special person to adapt, to want to do that for the entirety of their career. Now, the concept of two versus four versus whatever.

People will tell you that three is probably the most optimal number. YC, I think does a red flag on one and five. So two, three, or four is what they consider to be a good number. But there are enough exceptions to that rule everyone has a different journey and it’s all about what’s right for you.

A single co-founder is really challenging because you have no one else,  sitting next to you that understands what you’re going through to balance you out.  The beauty of multiple co-founders early on when you’re not making any money, you’re putting in crazy hours you’re not able to pay yourself. If you get stressed out and you think that maybe this is a bad idea. There’s literally no one else there that’s sitting next to you saying, you know what, actually, I think we’re okay. That’s the problem with one founder. And then when you get to four or five, six co-founders and there are just too many voices in the room and how do you come to decisions? You gotta have a really good structure. 


You guys were working, for the most part, almost every day, but what were your outlets to take a break from the program and just decompress.  


It was wake up, roll out of bed, sit down at the desk work, maybe get up for meals. Work until I don’t know. I think I worked until four or five in the morning pacific time. I’d call my girlfriend at the time as she was waking up to say good night cause she was on the East coast, sleep for a couple of hours, and do it again.

We crushed that hard for three months.  No real breaks. The outlet from that is taking a walk but there are no weekends,  nothing like that during YC. Cause it’s a three-month sprint. But for my wife, girlfriend at the time, the outlet was when we were done we took a trip to Costa Rica to unwind just fully shut it down for a couple of weeks.  You have one opportunity to do YC so our opinion was to make the best of it. And you got to do whatever makes sense for you. The whole startup thing is a marathon, not a sprint.

If you know that that is going to cause you to burn out, then don’t do that. But if you know that you can do that and then take a break like I did at the end. And have a couple of weeks to decompress and then you’re fine then. Yeah, that works for you.  Everyone’s journey is different.

And no one path is right. That sounds absolutely intense.  It’s just five guys living in a house all it had was desks, a mattress, and a shitty TV like there’s not a whole lot else to do other than take a walk in a suburb in Palo Alto. It’s not as crazy as it sounds, it’s just life. 


Yeah, I guess when you’re limited by time in a program like this, you really have to make the most of it by continuously working on the product. But you guys graduate from YC, you’re in the Valley. I know you stayed out there for a little bit but walk me through that thought process and personal decision you had to make on whether or not it made sense to move out to the valley especially with your significant other. How’d you go about doing that as I’m sure that was a hard decision to make and even convince your partner at the time. 


We are from Toronto, from Canada, we spent the time in California. What we wanted to do for the startup was what we thought was best for the startup.  It wasn’t so much about where we personally want to be. It was more so about where we thought that we’d stand the best chance of succeeding.

When we came out of YC,  we thought about our product.  We thought in a bottoms-up growth perspective. So tackle individual engineers grow through that community and have that community pull into the companies.

We thought, hey, the best place to do something like that, the best place to be a tech startup is in San Francisco so we figured that’s where everything’s happening so that’s where we should be. We did a couple of walks and talks to come to that decision and then as we were nearing it, talked to our significant others and asked them graciously if they would come with us for what could potentially be an indefinite period of time down in San Francisco and everyone was nice enough to say yes. 


Did you guys have a one-year plan of hey, let’s stay here for a year, and then maybe we could potentially go back?


Andrew sold his house and had no plans on coming back. So no, we didn’t have any specific plans.  I personally pegged a 5 or 10-year thing. I love Canada, love my family. I didn’t envision myself moving forever. But I was willing to spend as much time as we needed for the company.

I can’t necessarily speak for Aaron or Jonathan or even Andrew in his decision. But I think everyone was at least on the same page, it’s not just like a one-year thing. Like we’re planning to move the company down here. 


Wow, that’s amazing that at least all 4 of you were by the sounds of it committed to doing what it takes. This is more so a question from the perspective of someone, who is looking to get into YC,  but what prompted you guys to move back to Toronto? And what is some advice you’d give to someone who is looking to potentially move back or stay in the Valley? 


We spent two or three years total between YC and afterward in San Francisco. I think our thesis that we realized didn’t really hold true.  We thought this is the center of the action.

This is where we need to be. This is where our customers are going to be.  So we got through a few years down there and we crossed,  a million in ARR, maybe close to that, but we picked our heads up and realized that not a single one of our big customers was in San Francisco.

And realized at least from a customer perspective, it wasn’t exactly necessary to be there. We also realized that the vast majority of the great talent we were pulling in was actually people recruited from  Waterloo co-ops that we were importing to the U.S. So between that and  I don’t know if anyone ever reads  Gary Tan’s articles.

I know he used to post a bunch of things back in the day on this, but the vast majority of VC funding to startups actually for a long time, was just flat funneling straight into San Francisco real estate because real estate costs so much.  We looked at where our customers were looked at where we were getting talent, looked at where our costs were going and I don’t think any of us wanted to be there forever.  So after the two or three years that we were there, we kind of realized that it would probably be easier to support our clients from the East coast. We could probably more easily get talent from like while we were in Canada, through our networks, and through everything. And so we just said, hey,  there’s not a whole lot keeping us here. We had a few employees at the time.

We were still pretty small, like under 10. So we just decided, given all the things that we know about it, we actually could have a competitive advantage moving back. So we made the decision. 


Do you think that still holds true now that you have been back in Toronto for a couple of years? Or are there other challenges that you may have overlooked? 


I think that the concept of a startup needing to be in San Francisco doesn’t really hold true anymore.  There’s probably a period of time where that held true. I think what matters is being where it makes sense for you as a startup.

If you are a FinTech company, it probably does not make sense for you to be in San Francisco because there is not a whole lot of financial companies there, you’ll probably be better off than London or New York, or even Toronto. If you are a mining company,  if you’re trying to be a startup to handle something like that, San Francisco is not the place for you. Go to Denver or go to Calgary or go to wherever it makes sense.  Now, the important thing is the value of the Valley is the attitude and the understanding of the competition level. You want to be able to understand that wherever you locate.

So wherever you locate, you should be trying to get as much value as you can out of whatever the relationships may be and you should be trying to spend time and understand what the startups are doing everywhere. What matters is what is important for you as a company.


So you’re in Toronto for a couple of years now. You have realized that you don’t have to be in the Valley to successfully grow a tech company and the problem has always changed. So how did you go about understanding your product-market fit? 


Yeah, it’s interesting. I think, as a startup, it’s healthy to always have skepticism about product-market fit. Until you are, tens or hundreds of million a year in revenue, the concept of saying, oh, we’re confident about our product-market fit, is dangerous. So  I’ve never personally felt comfortable with it and never said oh yeah, we’re a hundred percent confident.

It kinda comes back to that same thing I was talking about before charging for products. It’s that idea of what are people willing to pay for the service or the product that you’re providing? And constantly evaluating that and for the most part, it’s a balance between that and the total uptake. 

Like, are you getting a lot of customers? Are you getting interest, and I think as the market changes around you, you constantly have to re-evaluate that.   For us,  we’re in the enterprise space,  we have a suite of products.

We provide a blend of products and to some extent services and the thing I always talk about is making sure that people understand the value of the things that you’re providing and making sure that they are actually willing to pay for those things.

And that’s the crux of it. For us, it’s really easy,  have a product that I’m selling to a person. If a person’s not willing to buy it, then I don’t know the fit. But for a consumer-based company where I may actually be selling ads or it’s not your data for the value. Then it becomes a lot harder like what kind of growth trajectory is sufficient to say that you have a fit and that will be sustainable and will have a high degree of value. That’s a lot harder to assess. But everything has its own challenges. It’s not like anything’s easier or harder than anything else. They have their own complications.


Following that same line of thought in terms of determining product-market fit and trying to find kind of a sweet spot where you’re providing value for the customer.  The Taplytics product has changed and evolved so much since Taplytics inception. We’ve expanded to other platforms like web, server-side and so on. So how do you decide,  what path the product roadmap takes? 


I think it always extends one from the product vision, but two where customers are pulling you. Our vision for our product was never to be the best A/B testing company.

We didn’t start as A/B testing. That is the place where we launched and got our first paying customers, but that wasn’t where the startup started. The whole concept originally was this idea of taking native mobile apps and being able to change the look and feel dynamically on the fly.

And the whole purpose of that was the quality of the user experience on native and want to blend that with the flexibility of web technologies.  When we decided to go down the path of AB testing, that was because when we first got our products in the hands of users, they were like, this technology is super cool.

I love what I’m able to do with it, but I don’t really want to build my app in it. What I want to do is edit this single part of my app, figure out what’s working, not working, and then bring that back into native code. So our customers pulled us into A/B testing.

Now, as we went through the process of tackling that our vision for the whole thing became how do you help people manage user experiences across a number of different platforms.  That to me is the real big challenge that isn’t yet solved that we’re trying to solve and that vision is the thing that then drives you as you progress.

You have to have some central vision. For us, it was this idea if you have a massive brand out there and most of the companies that we ended up starting to work with were these big brands. The problem is less so A/B testing here or driving personalization over here it’s this idea that they now touch their customer, on their website, mobile apps potentially an app on  Android Auto and CarPlay.

If it’s a restaurant, they now have a kiosk. They have email and push notifications. They have all of these different places that have digital touchpoints usually managed by completely disparate teams. So how do you make sure in that landscape that you have a unified experience for that person who touches your brand?  That has always been the thing that guided us. So as we were being pulled in certain directions, you kind of put the guardrails on where you go based on that vision. 


I wanted to focus on something you said around being pulled into different directions, and sometimes as a SAS company, we can be pulled in directions by the large enterprise clients that you have. How do you balance customer needs, wants, and feature requests between what you and the product team envision what you want Taplytics to be? 


It’s a constant challenge. You’re always looking at the things that you can build, whether it’s things that you come up with internally or things that are requested externally on a matrix equation.

You’re always trading off value against effort and whether it comes externally or you’re coming up with it internally. External is easy. Cause it’s basically, market research done for you. The thing that you need to do internally is making sure that whatever you’re coming up with, isn’t just you putting your finger up in the air to the wind.

You have to have some reason for thinking that this thing is going to be valuable for your customers. And ideally, that’s you talking to your customers, that’s you doing market research,   so whether it’s coming from a feature request or otherwise it should ideally look the same, it should be the same kind of evaluation that really understands the value versus effort equation.

Then you have to make some tough decisions cause you’re never going to have this ordered list handed to you. You have to make trade-off decisions, you have to have hypotheses about what’s going to be easier, better or worse, and take a guess and hope for the best. And then ideally you do retrospectives, figure out if your assumptions held true, and then try to take that learning and feed it onto the next cycle. 


And speaking to when you mentioned that getting firsthand external market research, by being able to talk to customers how do you feel that your experiences bouncing between customer service tech support within Taplytics has influenced the way you make product decisions and prepared you for this role of head of product and engineering?


When you’re building a product, you are building it for a customer. A lot of people forget that sometimes whether it’s engineering or product.  A lot of times a product gets built for product sake, but you’re building it one to create value for the company, but value for the company is only created because a customer sees value in it and will pay you more or continue paying you or continue using your product because of it. So I think the most important part of anything that I’ve done, that’s like work with customers, it’s helped me have empathy for that customer’s needs.

And I think that’s critically important, whether you’re an engineer, product manager, head of product, VP of engineering.  Having empathy for the customer, understanding their problems, and digging in to get to the bottom of the things that are important to them is the thing that will make you successful.  If you don’t have empathy and drive out decisions from that, I don’t think you’re gonna be successful.  


Diving into the importance for both product and engineering to have empathy for customer needs. I think a lot of SAS companies struggle with the fact that customer success, tech support, maybe operate in different silos to each other, and sometimes the problem that you’re trying to solve with the product is lost on engineering and there’s a gap in terms of understanding all this work that engineers are putting into to build this product and what it’s actually empowering customers to do. So how do you bridge that knowledge gap between product and engineering? 


It’s the fundamental reason why startups have an advantage over big enterprises when it comes to launching products. When it’s less than 10 of you around a table, it’s not that big of a gap between, customer success, tech support, and product and engineering. 

You’re all there in a room. If someone has a support request, you’re dealing with a fire at the same time. It’s as you grow that you begin to have that separation. So the most important thing is how do you break down those silos and that as a founder and a team lead for me is one of the biggest things.

As we grow a question of, how do you ensure that these teams communicate and the information passes smoothly and everyone knows the problems that are happening in one area or the other how does that come together? That is a huge challenge. And every stage you grow past,  whether it’s going five to 10, 10 to 20, 20 to 50 people, each of those pose different challenges.

I’m not going to say I, or we are perfect at that. But that is to me, probably one of the biggest challenges that I think is important for me and our company to handle.  That ability to keep communication flowing smoothly is the thing that drives competitive advantage.


I know it is a struggle and it’s cool to hear your perspective on that coming from a customer success background and being in the weeds with all of our current clients. They too, as B to C companies are always trying to close that product feedback loop between creating products that their users actually want to use. I am curious to hear more of your perspective about eating your own dog food in terms of running out experiments, leveraging feature flags, and improving our own product feedback loop to understand if users are liking our product or the product decisions that you’ve made. 


Yeah. As an A/B testing feature flagging, personalization company, obviously we have those tools. It’s not always easy to say for the painter to paint his own house or the carpenter to build the improvement at home.

We always struggle with the same things that everyone else does or do you just build and ship or do you work through that process that you preach?  I’m not going to say that we are the perfect company at that, but, that strive to leverage the tools it’s really important because, where I sit and now leading product and engineering,  I truly believe that these tools are insanely important for delivering for our customers. So this idea of leveraging feature flags to have engineering be able to flow separately from the product management release cycle, have deployments to production for code, be separate from the concept of feature releases with go to market and product. That allows efficiency that drives quality higher in terms of experimentation, personalization, being able to leverage those tools to constantly improve the product. I see those as critical tools for me and my team to be able to be successful.

And my number one, driver beyond communication is making sure that we leverage it the way our customers do and making sure that we don’t fall into that trap of,  the carpenter that doesn’t fix up their garage for years because they were fixing up things for their customers. So I think it’s important.  


I’m going to finish off with a couple of tough questions, one a little bit more lighthearted than the other, but I’ll hit the tough question first.  Do you feel like you’ve made any product decisions that maybe backfired? I’m curious to know what we did as a team to pivot out of it or what was learned during that process?


I don’t think anything is ever as black or white as that. There are certain cases where like, Oh man, this blew up and it was great. And we’ve had things like that, which was super cool.

You rarely have things where it’s like an abject failure. Sometimes you do and those things are generally really easy to spot like 99.9% of the time it’s actually somewhere in the middle in the gray area. And that’s, where the data and the testing really comes in and becomes extremely helpful.

You need to constantly be checking your assumptions, constantly adapting and iterating because yeah, I don’t think we’ve always made the best decisions. But as a startup, it’s easier as we grow, it’s going to be harder. And this is the thing we’ve got to stick to, is that idea of being willing to launch stuff, learn from those failures, learn from the challenges that you have.

And make these slight adjustments is extremely important. And if something blows up in your face, that sucks, but it’s actually better than when it is a quiet failure because you know when you can move quickly. 


Last question, there’ll be a lighthearted one, but what has been one of your proudest product moments at Taplytics so far?  


We made a massive leap early, early on that I was always really proud of.  I think we figured out pretty quickly that our product wasn’t something that was that bottoms-up, grassroots developer thing, like an A/B testing tool, needs a base of customers. And early on  I think our first big contract was four figures and that was one of our first contracts and then we jumped pretty quickly to a six-figure deal and the validation as a team of like four at the time being like basically the person responsible for taking that initial part of the product and being able to see it validated with a major multinational corporation that was willing to pay six figures a year for it.

That is hugely validating. The other piece, to be honest as a co-founder that had some failed startups in the past, one of the most important things for me, at least from a product perspective was always just building something that people actually cared about and used. So, even when it’s a pain when people notice issues or come to you with customer success problems, it is extremely validating to know that someone actually cares and someone cares enough to create a support ticket to say that this thing is causing them problems in their workflow means that they care enough about what you’re doing. And from at least the broader startup perspective as a founder,  it is extremely validating to know that someone cares enough that if you cause them problems,  they actually are going to complain.

Cause the worst thing out there is that they just say, fuck it this isn’t worth my time.


And there you have it, folks, that was Cobi Druxerman talking about his journey through YCombinator and how he thinks about product strategy at Taplytics. Now before we go we just wanna say a big thank you to Cobi and to Taplytics for giving us a chance to host this podcast. If you’d like to connect with us you can reach us either directly through the website at or on Twitter @Taplytics. If you’d like to connect with Kate or myself personally, you can find us on LinkedIn but we hope you all enjoyed the first episode of The Product Shop and stay tuned for more episodes to come.