Tim Buntel has built his career by solving problems to improve the lives of people in his communities. He is VP of Product at XebiaLabs, a development operations company that partners with developers to help build exceptional software faster. As a self-taught developer himself, Tim’s insights into the day-to-day challenges of new developers is instrumental in building a great product people love. Tim is passionate about changing the landscape of the tech entrepreneurship scene in Boston. He’s a board member for Smarter in the City, an accelerator dedicated to investing in people and neighborhoods left out of the conversation that usually swirls around the Kendall Square and Seaport startup communities. Tim’s focus and talent of building up the people around him make him a Product Hero.
I had the pleasure of sitting down with Tim to talk about product management at XebiaLabs, the evolution of his career, and his involvement in the community. Below is a condensed and edited transcript of our conversation.
Evan: I’m lucky to be joined by Tim Buntel, VP of Products at XebiaLabs. Thanks for spending some time with me today Tim.
Tim: Thanks for having me.
Evan: I’d love to get a better sense of your background. What have you been up to the past couple of years?
Tim: My background is primarily in developer tools or software products that people who build software for a living use. I’ve worked for a number of companies in that space, Atlassian, Microsoft, Adobe, recently a startup called Codiscope, and now a development operations (DevOps) company called XebiaLabs. That’s pretty much been the focus for all of my career; making software that software professionals use to build their own products and to make that job easier and faster.
Evan: What brought you into that role?
Tim: It goes way back to the early internet days. I was a developer myself. I started off writing code for a living back in the ’90s. That was during the first wave of the dot-com days, and I was using technology as a developer that was offered by some vendors.
One particular vendor here in the Boston area was a company called Allaire, which was the first commercial internet application server company. They had a product called ColdFusion that any folks who have been around in the web development world for a while might recall. I was a user of that product and then joined Allaire. Because I was a customer and a user of the technology, I was a good fit to come on board and help them with their product definition and moving the product forward as an archetypal user.
Evan: How did you decide to make the transition from developer to product manager? Or did you always have that in mind? Why didn’t you just stay as pure developer?
Tim: Honestly, I think probably at the time I had never even heard of product management. In those early internet days you saw a lot more people who were coming from less technical backgrounds.
Our customers were coming from this much more content driven web world writing HTML, maybe doing a little light scripting, but many weren’t computer science majors. For me the interesting opportunity was to bridge the gap between the really technical engineers who built the software and the less technical emerging type of web developer who was building the client applications.
I come from a non-technical background. I don’t have a computer science degree. I was a largely self-taught programmer, so I could relate pretty well to those new types of developers that we wanted to have as customers. Yet I had grown to be more technical over the years of doing it, so that I was able to have the right depth of technical conversation with the engineers.
Evan: Let’s talk about your role at XebiaLabs. What’s your focus there and how did you get involved with the business?
Tim: My focus has been on the developer tools primarily. XebiaLabs has been around for about six years now. You would classify us as a DevOps company, but we really look at the overall process of building high quality software faster.
We’ve got a lot of tools for the developers writing code. We’ve got great frameworks. We’ve got good tools for testing and managing source code and collaborating together, but there are still a lot of gaps in the overall process of taking an idea and then getting it into the final state of software that’s being used by an end user. Thinking about that overall process, that’s what XebiaLabs does.
I head the product team. We have product managers and user experience folks on the team with me. We work very closely with engineering to put the solutions into the products. Then, we work with marketing and sales to take that out to the market.
Evan: I want to shift gears to a special project of yours. Tell us about your involvement in Smarter in the City.
Tim: This is a great project that I’ve been really honored to be involved with from the very beginning. Smarter in the City was founded as a way to support tech entrepreneurship in some of the underrepresented communities in the Metro Boston area. We’ve had the great fortune to have amazing startup neighborhoods in Kendall Square and in the Seaport District, but some of Boston’s other neighborhoods have been left out of that.
It started down in the Dudley Square area at Roxbury, looking at entrepreneurs who may have not had the same access as some of those other neighborhoods but who want to build businesses and solve problems that are really important to those neighborhoods. That’s what we do. We generally have a cohort of four to six startups at a given time and a program that lasts anywhere from four to six months, with certain startups staying on for a longer engagement.
We offer many benefits like other accelerators: Dedicated mentor partners from technical, legal, marketing, and all kinds of other disciplines. We’ve had a number of our startups accepted and go through MassChallenge. It’s open to anyone. The pool of applicants is growing every session, with fantastic diversity in the participant base.
We are particularly interested in helping entrepreneurs who have been underrepresented in the startup community; folks who are also looking to solve some of the problems here in the Metro Boston area and in some of the communities that the participants are coming from. Obviously a great entrepreneur has a close connection to the problem that he or she is solving, right? That’s a key ingredient for success. The portfolio has included a wide range of industries; everything from beauty professionals, to fitness, to fashion, to education.
We are always happy to have mentors who want to get involved. We are totally non-profit so we don’t take any stake in the organizations who come through the program. We’re there to help serve the entrepreneurs and inject more diverse voices into the startup scene here in Boston, which I think benefits everybody in the long run.
Evan: Shifting back to XebiaLabs, what are some of the biggest challenges? What’s the stuff that’s keeping you up at night in your current role?
Tim: There’s a bunch. XebiaLabs started in the Netherlands outside of Amsterdam, but now the headquarters is here in the United States. We still have engineering in the Netherlands.
We have some of the classic challenges that you face with trying to have a high performance Agile team when you’re distributed. We have stakeholders in the U.S. and we have stakeholders in the Netherlands. We have customers throughout the world. We have sales engineers, and marketing, and sales throughout the world. A focus now is how to scale that well and how to keep that kind of startup, close feeling and that sort of scrappy responsiveness while still scaling the organization globally. That is always challenging.
Another thing is probably something that lots of product folks are familiar with – the need to constantly think about experience. In developer tools, for many years we never bothered thinking about that. We weren’t investing on the user experience side as much as you would in a consumer facing product. The reality is, making software that’s really intuitive, and that’s pleasant to spend your time with, and that’s performant is just as important to a software engineer as it is to a banking consumer.
Evan: Do you guys use personas? How do you make sure that when you’re building something, you’re building for the different types of customers that you have?
Here at XebiaLabs, we are actually expanding our collection of personas because our products are used by more and more people outside of the traditional development world. Originally we might have had just a developer, a tester, and maybe an operations person, but now the number of folks who are involved in software releases in this sort of new world of the digital enterprise is much broader, right?
You’ve got business stakeholders. You’ve got risk and compliance people that are looking after security. You have auditors who are looking after all the regulatory issues that come up in certain situations. We really have to think about all of their needs interacting with it as well. My challenge right now is to keep the list of personas manageable. The Shakespearean cast of characters that we have to think about.
Evan: Yeah. How much is your team interacting with those actual customers? How often are you talking to the customers?
Tim: Yeah. It’s always a struggle to do it enough, but I think we’re pretty good here in this organization at doing that. Luckily, this topic of DevOps, continuous delivery, and software development in general is really at the top of mind for a lot of organizations right now. You can go to pretty much any city on the planet, any night of the week, and you can find a meet-up, or a conference, or some sort of opportunity to reach new customers.
We also have a really engaged set of existing customers, so we have a great relationship with our current users who we can talk to for feedback. Since it’s also a growing market, there’s lots of attention from press and analysts as well, so we can get into some of those customers through that as well. The product managers here are really heavily outward facing.
Evan: Got it, okay. When you’re doing that interaction, is it you or someone else? Is it the product managers that are doing that interaction, or are the developers and designers getting involved as well?
Tim: Yeah, sort of all of the above. We had a big customer event in Amsterdam just a week before last and we brought over a number of folks from the engineering organization and they found that incredibly helpful. That customer event was some of our users giving presentations on their own use of our products. It was meant to be a peer-to-peer best practices sharing session. The engineers found it incredibly helpful to hear in our customers’ own words how they were using the products that the team was building every day.
Evan: In terms of keeping everybody on the same page, what role does roadmapping play in your process?
Tim: Yeah. We’re working on all of that now. Obviously it’s important to know where we’re going. What we try to do is be very clear that there’s a spectrum of ways to talk about what we do as a company – from the kind of long-term higher level things, all the way down to the really short-term specifics of what we’re building.
Our roadmap is part of that spectrum of strategic sort of communications, right? On the far end, we have our corporate strategy, then we get into product strategy, the product roadmaps, and finally the actual product backlogs.
Evan: Okay, got it. There are sort of different levels of roadmapping.
Tim: Yeah, exactly.
Evan: One for business, one for the high level where are we going, and then there’s kind of the release plan that’s more detailed on what are we doing on a day to day basis.
Tim: Right. The product vision is really what are our products are going to deliver and for whom, but it’s a bigger view – maybe two years out. Then we get into a product strategy, which is more of how do you attain that vision. That could be your value proposition. It could be key feature areas. We also include business goals there. That strategy might extend a year or so out into the distance. Key feature areas tend to change once you get much past that sort of horizon. The roadmap is even shorter – maybe six months out. It tells how the key features will come in actual releases.
Evan: What do you think is the biggest mistake product managers make when it comes to roadmaps?
Tim: I think the world that we’re in right now is very fast-moving. I think a challenge as product manager is to allow yourself to be flexible with your vision and understand that these things can evolve really quickly. You need to be able to go along with some of those natural evolutions that will happen and will throw chaos into that roadmap, right? The desire for structure and order is pretty strong I think.
Evan: What’s one of the biggest product management mistakes you’ve made in your career? Can you think back to a specific time or experience, maybe an interesting story?
Tim: I think one of the challenges that I’ve had in product management, especially in going from company and company and working with different organizations, is that product managers each have their own set of preferred tools.
When I’ve come in and transitioned teams to the tools I use, you can get some friction with other parts of the organization. They don’t necessarily want to adopt your specific toolbox.
Evan: How do you measure success? How do some of the PMs, or how do you in particular, measure the success of the work that you’re doing?
Tim: A lot of the things that we’re looking at are around efficiency. We measure how well we are empowering engineering to quickly work on all of the items that we’re hoping to build. We’re trying to shrink some of those processes. We’re always thinking how we can shrink that process of going from an idea through a validation process with our customers. We have some metrics around that that we’re setting up.
We also set some purely self-driving metrics, like making sure that people are doing evangelism activities both internally and externally every week or every month. These kinds of interactions make sure there’s a balance between talking to existing customers, but also talking to prospective customers, or talking to consultants or sales engineers, that sort of thing.
We tend to use metrics around that, because our days are really busy and if we don’t say every week, “I need to be talking to these people,” you can tend to lose sight of some of those. It’s a mixture of metrics on how the work that we’re doing is improving our ability as a company to ship the right product as fast as possible, and metrics around how we as product managers are either communicating what we do to the market and to the company, or gathering the input that we need to help drive those decisions.
Evan: What advice would you offer somebody looking to become a product manager?
Tim: I think the most important thing with product managers is to think about who your people are,who is your tribe. A product manager is really going to be that voice of the customer. That’s very kind of cliché term now in product management, but make sure that you like the people. You’re going to be their advocate, so you want to be able to really walk a mile in their shoes and be the person who believes in them.
Evan: If you could learn one thing in an instant right now, what would it be if you could just download it into your head?
Tim: If I can learn one thing, oh well it will have to be how to speak Dutch since half of my team is in the Netherlands.
Evan: There you go. Tim, thanks for joining us for Product Hero. We really admire everything you’re doing for the community.
- Advice for up-and-coming product managers: be the voice of the customer.
- On product success metrics: XebiaLabs includes how many times they’ve engaged with customers each week.
- Learn more about the Smarter in the City including how you can be involved.
- Connect with Tim on Twitter.
Know a Product Hero? Email us with who we should interview and their contact information.