“I realized at some point that all programming languages are the same.”

Leif Singer | Head of Product at iDoneThis

Interview by Thomas Peham

June 18, 2015

Photos by Leif Singer

Leif Singer. Startup product manager by day. Researcher by night.

Having grown up in Germany, Leif chose a career in software engineering. When joining the University of Victoria in Canada, Leif began to study how developers collaborate and work with others.

Now working as the Head of Product at iDoneThis, Leif is shaping modern team communication and helping people get more things done. Setting the vision and direction of iDoneThis requires gathering a lot of data through surveys and talking with well-known customers such as Twitter or Buffer.

Share this interview:


Hi Leif, thanks for your time. Can you please describe yourself?

Thanks for the opportunity. I’m working as a product manager at iDoneThis and I’m working on defining the product for iDoneThis. I figure out what we want to build and then help our developers build that in the most efficient manner which often means sketching workflows, creating mockups, creating wireframes. One important aspect is watching out for scope creep to scope projects very very tightly so that we are always just trying to build the smallest thing that will get us where we want to be. Every feature we have needs not only be created but also maintained.

Then I also do some more strategic thinking on what we want to build next.

Okay and how do you make sure that you keep everybody on the same page?

There’s two parts to it. One thing is figuring out what to build. This means conducting user research, talking to users, doing surveys, doing polls, looking at analytics, things like that.

To make sure we are synchronized as a team, of course we use our own product iDoneThis which is perfect for remote teams. We also use Slack for more synchronous text-based communication. We usually have regular one-on-ones between a bunch of team members.

For example I have a one-on-one with the CTO and one of the developers every week. We’re kind of undecided on what tool we actually prefer to use there. Right now we’re trying out speak.io which is also a very recent app that a few other startups that we know are currently using.

What do you find most rewarding about your current role as the Head of Product at iDoneThis?

My main task is to enable our developers to do their best work. It’s super rewarding when I see that happening and everything goes smoothly. Or when I am able to remove the obstacles before they reach them. That’s the most rewarding thing.

Do you have any aha moments where technology really clicked for you?

Originally I wanted to be a writer. I think we got our first internet connection in 1996. Back then I wanted to publish all my bad youth poems and stuff like that and so I had to learn HTML one way or another. I hung out in chat rooms, which still allowed HTML at that time and I experimented with that a bit there. I think from there on just one thing led into another. One thing led into another and then I had my own website.

I actually co-founded another startup around that time in 1999. Then I started studying computer science and basically did most of my work in PHP. From then on I did some Java again. I was super scared when I joined iDoneThis because we are using Python and Django and I had never used them before. But I quickly got the hang of it because I knew all the important concepts from other languages and frameworks.

I realized at some point that all programming languages are the same.

Now I’m working in Python and Django. For now that’s the current state, that’s where I’m at right now.

What was actually the reason for you to leave the university career behind and start at iDoneThis?

I started the postdoc in Canada right after I got my PhD here in Germany. My reason for doing a postdoc was that I wanted to become a professor at some point. I have a wife and now we have two kids. We realized that being a 24-hour flight away from any support network with family and friends was not what we wanted in life.

If I had continued with the postdoc and with the academic career it would have meant that I would have had to choose a position as a professor anywhere in the world.

There’s just a tiny amount of professorships available so you have to go where the positions are. Remote work of course then was a perfect opportunity there.

And what was the reason to start at iDoneThis?

That’s funny. I got the postdoc in Canada because I read a tweet and based on that tweet contacted the professor in charge. It was the same with iDoneThis. Twitter is really the best social network for jobs in tech.

I had used iDoneThis before because I wanted to track what I was doing all day. So I knew the tool and when I noticed that they were hiring, I wrote them an email. And a few months later I started at IDoneThis.

I think you also did some studies on how software developers collaborate on Twitter, right?

Yes, that’s true. I studied how developers use Twitter. Looking for jobs on Twitter was also a theme that we discovered in our studies. Besides that it’s mainly about finding clients, using it for professional networking and stuff like finding local connections.

Have you seen any local differences on how developers use twitter?

Yes we did. Some people said that when they moved to a new city they saw a few people on Twitter who were in the same city and were able to meet with them at meet-ups connect with them.

In more remote regions or smaller cities people said, “Yeah, Twitter is my way to connect with basically the world of web development, because locally there is nothing going on.”

Is there any advice you would give yourself as a 14-year-old?

It’s going to be all right. Don’t worry.

Can you share some challenges in managing product at iDoneThis?

We’re a pretty small team – five people and out of those there are two-and-a-half developers. We have to be very careful when we decide what to build next. We want to have the maximum positive impact for our users and customers with ideally the least time investment.

I think that’s the most challenging part right now for us, and for me specifically.

However, perspectives change all the time and that’s where we try to use data such as quantitative surveys or polls, customer interviews, and analytics data.

Data on the one hand and on the other hand we’re continuously working to refine the vision we have for what iDoneThis can be. We try to combine those two things to guide what to build next and how to build it.

Is there any technology or tool you would like to explore?

If I had more time I would probably want to look more into exactly these tools that support you in product management. I have a list of tools that I would want to use. Right now we’re still experimenting with more lightweight tools like Hackpad, spreadsheets, things like that.

Is there tip for staying up-to-date in the field of software engineering?

I guess for engineering we use Django and Python and that’s not really quickly changing. I think the main thing there is just to use it – to practice and to get better at it, and to follow not so much the technologies but the practices that people are exploring.

We have a subscription to the destroyallsoftware screencasts, which introduce things like how do you practice TDD well or how do you get the most out of your editor.

Staying on top of current practices at this point is really more important for us than technology.

How do you handle tracking bugs at iDoneThis?

For bug tracking we use GitHub. We use different classes of issues and on GitHub we only really track the ones that are clearly bugs and are clearly defined and can be clearly solved.

If a developer reads the issue and has two hours on their hands they will be able to solve it. Everything else we put into a Asana, because that’s more likely to be something like a bigger project that we have to scope, and have to spec out a bit more.

We also remove features from time to time because we realize nobody uses them or not enough people use them. Removing the technical cruft that isn’t used anymore then is a kind of an issue because it’s not really refining the product but it’s a task. And this task goes into Asana.

How can I imagine testing if you implement a new feature. Do you have some kind of workflow for that?

We try to write the tests for the things we write ourselves. Sometimes it seems more prudent to just get the feature written first. We’re very very careful about pushing code that hasn’t been tested.

We’re trying to adhere to good testing practices, on the other hand try to balance that with being reasonable. Everyone writes their tests themselves. That’s usually the case, sometimes not. Sometimes we do some pair programming.

In more general terms: In what directions are you trying to head with iDoneThis?

That’s a good question. We’re realizing that people not only use it to track what they did, but there’s also a lot of communication taking place.

For example, it’s a great replacement for daily standups that you spend less time in meetings and more time actually creating things.

We want to double down on that a bit to make it a better stand-up replacement to support more of the native things you would see in a stand-up. For example we have goals and dones now. The natural development would be to add things like blockers for example because that’s one of the things you’ll also talk about in a stand-up.

Apart from the stand-up-specific refinements, longer-term we’re looking to make it a better communications platform that’s asynchronous so it gets out of your way. Still you have to stay connected with your team.

Awesome. Thanks for your time!

Follow Leif @lsinger and iDoneThis @idonethis

Share this interview:

Check the other interviews

Get Access to Further Bug Tracking Resources & Interviews