“I would recommend to anyone, literally anyone, in any age group to at least just start programming.”

Thomas Schranz | CEO at Blossom

Interview by Thomas Peham

February 15, 2015

Photos by Florian Dorfbauer, Thomas Peham, Thomas Schranz

Thomas Schranz - CEO by day, growth hacker by night

Thomas Schranz describes himself as CEO by day and growth hacker by night.

Besides his SaaS business which he started since not finding the perfect bug tracking tool, Thomas publishes great content on product management & growth hacking.

Share this interview:

Can you shortly describe yourself in 2 to 3 sentences?

I studied computer science at the Technical University but didn't finish it. I dropped out to work on web applications for agencies and big brands like Red Bull and FIFA soccer and eventually got more into the very technical side of how to scale these web applications when you suddenly have a lot of traffic and at the same time the product changes from one day to the other. I think that was the main reason that made me curious about how software projects are managed.

blossom.io is an agile product management tool for building modern web/mobile applications. Blossom shows you who is working on what, the flow of a feature from inception until delivery and whether you are doing too many things at the same time.

How does a typical day in the life Thomas Schranz look like?

I don't know if there's a typical day, right now I'm researching databases. On other days I'm writing articles about project management, and on other days I'm figuring out how to improve our product without making it worse at the same time. I think there is no typical day.

You mentioned that you dropped out of college. What was the reason?

I think the main reason was that the things we worked on in the agency seemed to be more interesting for me. However, the formal education and the computer science background still helps me today building the products that I'm building now.

I think in the end it was just more fascinating to use the things I learned at the university and directly apply them.

Please tell me about your very own "aha" moment in your life where technology clicked for you!

There was an interesting "aha" moment. I played a lot of video games. We didn't have a PC where I could play video games because my dad is into photography, and he likes Macs but Macs didn't have any games on them. That forced me to use video game emulators on Macs, it was the only source for games for me. That led me to build websites about video games. I wanted to build a website with an actual tool for website-building like Dreamweaver, but again there was also no Dreamweaver on the Mac, so I had to learn HTML & CSS. This exploration of HTML, CSS, servers and operating systems taught me how things work. The main aha moment for me was when I realized that you can build things that people enjoy even with the simplest building blocks. You don't need complicated and expensive tools when you understand the fundamentals.

What is something you really like about being the CEO of Blossom.io?

I think a fun thing is being interviewed. If you are part of a company working on a product for a bigger audience, then, as a side effect, you will be someone people want to learn from. If you build a product in a certain space, then, in order to build a good product you have to understand the space and you have something to talk about.

In one of your talks you said you’ve started Blossom.io because you needed a proper bug tracking system. How did you end up building a project managing tool instead of a bug tracker?

That's a great question. I think in the beginning, we didn't really grasp what kind of system we wanted to build. Back then, we built marketing campaigns, e.g. interactive Facebook pages, and then the campaign went live. Once it was live, we saw bugs that we didn't see in your lab. So we had to fix those bugs and we also had to file the bugs to have some way where we could reference what is the thing that happened, what is the thing that should have happened. Like a bug case where you can track new evidence or new things that go wrong which, you can think, "Is this related to this bucket? Or that bucket? Or should we create a new bucket?"

And this process was a complete mess, so I think our first reaction was, "To solve this mess, we need a bug tracker," Because from our point of view, what the project managers told us all the time, "There are all these bugs and you need the fix the bugs." I think Rich Hickey calls this "easy" in the term of "nearby". In German it's "nahe liegend."

So we were like, "Okay, we have to manage these bugs so we need a bug tracker." But I think that the real problem was not having a process. That’s why we eventually ended up evolving the initial product which was a bug tracker, like a case filing system, to something that was more like a workflow visualizer.

That actually helped us to communicate with the manager, e.g. which things are we working on right now and how far these things are.

Has there been any major challenge while building Blossom?

Yeah, I think one thing with software in general is: the thing you build usually gets more complex over time. It is very rare that the thing is getting simpler over time. Usually your understanding of the space you’re in is not getting more complex. Your understanding of the whole problem domain is getting simpler because you understand it better, but at the same time, your code basically is getting more and more complicated. We still have, when you look at our code base, areas in the code base that reflect that heritage. It still reflects what the system was used for in the beginning, how some things are named and so it's not easy to change some of the fundamental assumptions.

The first thing is being aware that such things exist in the code base. The next thing are some core assumptions regarding how your architecture looks like and how your data model looks like, and this is hard to change. Some parts can be changed easily, other things are hard to change. I think we're still in the process of basically correcting all the initial assumptions. We’re moving from the initial problem to the problem domain we are in right now, yeah.

Can you share a couple of tools you're using on a daily basis?

Yeah, like, obviously we use Blossom. It's kind of self-referential, but one thing that really works is having a process. Especially if you do five different things that are really like programming and this and that, in order to not go crazy, it helps to have different tracks or different processes. It's easier to switch into one of these kinds of activities, and establish the context that you had before you left it last time. So I think that is one of the core things that really helps us, and me personally.

Then, we use Slack, a chat tool. We use Google Drive, we migrated from Dropbox to Google Drive. We use a lot of Stack Overflow. We use Intercom, Intercom is a really cool system for customer support. Also Google Analytics.

Is there any technology or project or tool you'd like to explore at the moment if you have more time?

Yeah, oh yeah ... you got to me at the right point ... There is a database called Datomic, from a guy called Rich Hickey, who's the creator of the Clojure programming language, and Datomic is very unique kind of database. They call it a fact database, it stores facts, and you can retrieve facts. It kind of sounds like the usual database, but the way that the database works is: it remembers everything.

It's an accumulative database. Let's contrast it with the usual database, e.g. you have in MySQL a database with a table of data. You might have entries in the table: say there is a customer, and his name is Thomas, and there's his plan, and stuff like that.

If the customer changes the email address or the plan, usually, the naïve way to work with databases is that you update data in place. So you actually delete information and replace it, it's place oriented. There was something before, and you replace it. If you then, for example, want to debug issues, e.g. a complicated case which happened over a period of time, like someone is not receiving email reports, you have this fact, like an email, that you want to find previous things from.

I would just look up this email address and look for the previous emails we sent, but they won't show up because it's a new email address and everything's for the previous email address, stuff like that.

Obviously, if you have some things that are really important, then you build yourself some kind of log or "versioning", kind of like what Wikipedia does.

But the approach of what Datomic does is to basically say, "This is the default." You can delete things in a sense, but they will always be a very efficient way to get the complete state of the database and the complete state of the table. Unfortunately it's proprietary, and there's no open-source version right now. But I think in a few years, every database we use will use something like that.

Is there any other project you want to explore?

Yeah, I'm kind of super interested in front-end architecture, how the data flows through the system. I think, in the last three years a lot of things have changed completely when you look at the web. I look at the current status quo, trying to understand where it's going.

A lot of these Datomic-like concepts I think will find their way into the browser, and into how applications are modeled inside the browser.

There’s React, which is a framework from Facebook that is not as popular in Europe, or anywhere in the world except in the U.S. right now. People still use Angular a lot but React is a framework that allows you to not worry about almost all the bugs or sources that we had in our application, which is storing information in the DOM. The DOM is a really bad place to store any information, but it's so easy, again it's nearby and you have the DOM already, it's in your hands, so it is tempting to put stuff into the dom. There even are data attributes, so you are kind of 'officially allowed' to put stuff in the DOM. With great power comes great responsibility.

You're quite well known for publishing a lot of blog posts in different areas like product management, design, growth hacking, so the question is: are you doing that just for fun?

I think that if it wouldn't be fun, I just couldn't bring myself to do it, so there is definitely a fun part. But the main motivation is to help people to become better at managing their software projects.

People give us their attention, they know that we are not only building some software that they can use, but also that we know our stuff and that we are helpful, and so I think that was right from a meta point of view. Delivering the actual software is really important but once you have that software you should invest in helping people get as much value as possible out of the thing you've built. Writing helps here. Writing is a very efficient way to build relationships with a lot of people, it scales really well. It's also great for yourself: when you write, you have to basically put your thoughts on paper, it's harder than talking, because you have to actually put it in words and read over it and basically do a lot of iterations

You mentioned before that you were interested in video games during your childhood. Is there any advice you would give yourself as a fourteen-year-old?

Yeah. I always wanted to make video games and I thought I needed someone to tell me that I can do it. So I didn't. I thought: "Yeah, I can't program, and learning to program is really complicated." I already knew back then that there are children being younger than me but already started with programming, and I thought: "Yeah, I'm already late." (laughs) I can never catch up to them, and I can never build a really great video game." And then, just by accident, while building websites I didn't want to update the headers and footers and the sidebars manually all the time.

I would recommend to anyone, literally anyone, in any age group to at least just start programming

So I learned about this PHP thing to automate a few of the things I had to do over and over again. And that was basically the beginning of the first software I wrote, a content management system for our video game review website.

Yes, I regret not starting with programming earlier, and I would recommend to anyone, literally anyone, in any age group to at least just start, it's not complicated.

Since I could learn programming, I'm sure anyone could learn programming. Yeah. People think like me back then, that it's super complicated. You can build really complicated things, but you can also write really complicated things with a pen and paper, but it doesn't mean that using a pen and paper is complicated.

Since then, you've worked for a couple of companies as a software developer. What do you think is the greatest challenge for software engineers nowadays?

I think one recurring challenge is saying "no" to requirements. If it's from a customer, if it's from your own team, if it's from yourself. When you're a movie director and you're doing a movie with Arnold Schwarzenegger, there might be this idea that blowing up that building is awesome. Part of it is an awesome idea, and still it doesn't mean you have to do it. You can do a different action scene instead. More isn't always better.

Saying "no" to an idea doesn't mean that the idea has to be bad. Saying "no" is the more taxing thing. We would have to explain it to everyone involved, convince them and then basically leave the meeting with low motivation for everyone. And just building the thing, even knowing it isn't the right thing, is the easier thing to do. When you direct a movie you have to arrange ideas and actors in a way that they make sense together and that they form a great story. It's the same with products. You arrange features in a way that makes sense. Often a feature that on its own or in another product would be great doesn't fit well into the set of features you are currently looking at

Sometimes saying "no" is harder than actually doing this thing.

Do you see any additional pain for software engineers in the field of software testing?

I think the main problems with solving bugs and incidents is being able to reproduce them, or more trivial than that, understanding what lead to them, like what actually happened. I think that the pain point is an emotional thing. The pain point is: I talk to this customer, the customer is frustrated, I'm frustrated because I can't fix it, I don't know what version the browser is, the customer doesn't know what version the browser is, if I could be next to the customer, I could fix it easier, but I'm not near the customer, so it's like the pain point is the frustration for everyone involved.

What helps is anything that can make that pain go away, or automated, or basically give you all the context that you need, and you don't need to go through an intermediary. So I think these classic things, like what’s the version of the browser, which operating system, what happened before, what was the state of the program, that's again why I’m so fascinated with systems like Datomic that help you answer questions like these.

Any information you can get, any evidence you can gather, it's kind of like solving a criminal case, basically. You want to have the information as it happens, right? And you want all the information. And I think back then, before we had DNA analysis, we didn't know what kind of information we could actually get, so it was like, "Hmm, we don't see anything. There was no footprint ..." Now we take a DNA sample, and it's really complicated to explain why it's there and stuff like that. I think it's similar to debugging software bugs: it's very similar to criminal cases, and sometimes you have this cold case that’s when filing systems and databases are useful.

How do you deal with such situations right now within Blossom.io?

Right now we file these cases and then we try to look them up again. One thing that really helps, tool-wise, is the App engine, the stack that we chose to host, it already gives a lot of this information.

I think we had a very trivial way of how we actually work on these bugs, but basically the insight that we get is really good. You get basically a log of all the different error codes that happened, you can slice and dice the data. You can query by dates, you can see the stack trace in line and you can click on it and you end up in the code base and you can examine the code.

There are monitoring tools and they give you a dashboard to see the overall health of the system, e.g. how many 500s are happening, what's the pattern? Does it look like a heartbeat, or is it random? So, having these tools makes it easier to find bugs and find it in the code base. This helps a lot.

But the actual process is traditional: a customer finds a problem, emails us or tweets us, or talks to us via Intercom. I think that's why Intercom is really useful because it lowers the barrier to report things.

So since we have integrated Intercom, we learned about bugs that obviously were problematic, but no one ever told us about because writing an email is a bit more friction than you want to go through when you're still in the evaluation phase of a product. You don't care as much about the product yet as existing customers do.

You've mentioned that you build software to make other people more successful. Would you describe that as your main passion?

Now, definitely that's the main source of motivation. In the beginning it was completely selfish, it was like, "We can't work like this, we need a bug database." We needed a bug tracker so we built it, because we didn't want to use JIRA or Redmine. We tried Redmine and then we had a thing that was built in Flash. It was really weird. Now that we've solved this problem for ourselves we're free to help others as well.

Maybe just one last thing - do you have a couple of influential resources, like books or blogs?

I would watch all talks from Rich Hickey. I think he really understands software and he's a computer science guy so he understands what's possible, and how new circumstances mean that you have to go back to these fundamental building blocks and assumptions and rearrange them and build new things. I would definitely check him out.

Des Traynor from Intercom: They just released a great book on product management which is a collection of some of the blog posts that they have so if you're looking for technical inspiration, Rich Hickey. If you're looking for how to build great products, I would check out the Intercom book, basically.

There is also an interesting book called “The Principles of Product Development Flow: Second Generation Lean Product Development” from D. Reinertsen. It's also about project management, but more like a physics or statistician's view on product management. It talks about queues, and capacity in the system and cost of delay, like how expensive is it to not ship a certain thing.

Share this interview:

Check the other interviews

The site was created on https://soundcloudgrow.com/ platform. SoundcloudGrow - developed for promotion on SoundCloud.

Get Access to Further Bug Tracking Resources & Interviews