We recently teamed up with Pivotal Tracker and Notion to host a product management networking event in Los Angeles called “Product Stack”. Over drinks and snacks at General Assembly’s brand new downtown location, we discussed tools and techniques with talented product managers from a variety of industries.
The focus of the event was on how product managers can plan, execute and measure their way to better products. The “product stack,” similar to a development stack of commonly used technologies for developers, is meant to be an ever-evolving toolkit — composed of both literal software tools and figurative tools, like prioritization models and communication best practices — to help product managers be more successful at every stage of the product development cycle.
We plan to hold more Product Stack events in the near future and to continue growing our toolbox. To start, we’re hosting a joint Product Stack webinar together with product leaders from Pivotal and Notion on March 15th — you can register here.
Suzanne Abate, CEO of The Development Factory and host of 100 PM (a popular product management podcast), moderated our LA event and interviewed representatives from each of the three companies about the problem that their product helps solve.
Jim Semick, one of our co-founders, discussed how ProductPlan started after interviewing over 70 product managers and learning that communicating the roadmap was a common challenge. Below is the video (and full transcript, if you prefer reading) of Jim and Suzanne’s conversation. (You can also check out Suzanne’s interview with Pivotal Tracker GM, Dan Podsedly on the Pivotal Tracker blog.)
Also in the interview:
- Benefits of doing exhaustive market validation before writing a single line of code
- Why we eat our own dog food at ProductPlan
- How to stay agile — even when you’re an enterprise-level PM
Full Transcript
Suzanne Abate (SA): Jim Semick, welcome.
Jim Semick (JS): Thank you.
SA: Thank you for joining us. You are the Co-Founder of ProductPlan. What’s ProductPlan?
JS: ProductPlan is web-based product roadmap software. We have companies all over the world using our software to visualize their product roadmap.
SA: It’s interesting that you built a planning software because as I understand it, you spent a lot of time planning what kind of business you were going to build. I’m talking a little bit about the journey that you and Greg took to arrive at ProductPlan. Can you share that story here with our audience?
JS: Sure. I’ve been in product management a new product development for almost 20 years. I was the first product manager for GoToMyPC and GoToMeeting, both Citrix products. Then I was part of the founding team of a company called AppFolio, which is based out of Santa Barbara, and they do B2B property management software.
In all those roles, I was at the very early stages of figuring out what the product was going to be. I wrote the original PRD, for example, for GoToMeeting. At that point, you have a blank sheet of paper. You can envision whatever you want the product to be.
I have a background in customer development and new product development, and in figuring out what new products are going to be. Who are the customers? What are the pain points that you’re going to solve? What are the features that it has to have? What’s the go-to-market strategy?
When we decided to start ProductPlan, it was essentially a blank sheet of paper, and it wasn’t even called ProductPlan. We didn’t have a name for the company. We had few ideas knocking around in our head, and based on my experience from starting and launching other products, we did extensive market validation. Some would say it was pretty exhaustive. We actually interviewed 70 different product managers to figure out what that product was going to be.
I’m a little bit detailed I suppose. I documented every one of those interviews, and asked people if we could record the interviews, and had my matrices, and so on. I tried to figure out exactly what the problem was that we were solving.
And so that was the beginning of ProductPlan. We actually had gone through this exhaustive market validation process before we wrote a single line of code. Unlike the lean startup method, where you start writing code, and then putting that in front of people, and scrapping it, and pivoting, and moving onto something else, we decided to do it right from the first moment.
But before that point, Greg and I talked a lot about what we wanted to have in terms of a company. We talked about the culture that we wanted to build. We talked about the size of company that we wanted. We talked about what type of product we wanted to build. We talked about whether it would be B2B or B2C. So we had that framework before we started picking product ideas to validate.
We went about it a little bit differently than I think a lot of startups go about it. I think a lot of that is because Greg and I have been around for a while and we’ve launched products before. We had an idea of how we wanted to do this ourselves.
SA: You’re a practical gentlemen. I think what’s interesting about it for me is that you hear so much about the story of somebody who’s got a $2 billion idea. And the only thing between them and this $2 billion idea is a company to build it out. And then they’re going to be rich, and they’re going to sell it to Facebook.
That’s rarely the actual story, but a lot of people start with the idea, and then if they’re lucky, figure out that it’s a salable, scalable idea. In your case, you said let’s just work backwards from what the market actually needs and create something compelling.
JS: Exactly. The original validation that we started didn’t have anything to do with product roadmaps. We did our pivoting very early on in the process. Our original concept was another product for product managers to help them track their customer interviews, and to help them catalog and communicate the learnings that they were collecting.
And while the market said, that’s an interesting idea, it soon became evident that the bigger pain point was around communicating the strategy, and around communicating the product roadmap. And so we caught on to that fairly early on, and did our pivoting early.
SA: What is the primary problem that ProductPlan is actually seeking to solve?
Maybe I’ll preface it by saying, for the benefit of anyone in the room who doesn’t know what roadmapping is, what’s a high level description of roadmapping, and how does your product help?
JS: Most companies have some sort of a document or some way of communicating to stakeholders, and to executives, and even to customers what it is that they’ll be building.
Sometimes these are PowerPoint presentations, and sometimes they’re spreadsheets, but there is some product that they’re using. Sometimes it’s Google Docs. Every product manager in every company has a stakeholder — whether it’s your end customer, or whether it’s the CEO, or whether it’s the VP of Product, you need to communicate with those folks.
And so the key challenge is that the current tools out there don’t do a good job of communicating the why. They don’t do a good job of explaining, why are we doing this in the first place?
I also think that, in a lot of organizations, there’s this preconceived notion that because it’s on the roadmap it’s the right thing to do. The executives might sit around the table and say, okay, this is what we’re going to be building. That gets announced to all of the employees, and maybe the customers, and maybe the investors. And then the product doesn’t do very well.
So what we’re trying to do is connect the strategy of why you’re doing something with the end result, which is building x, y, and z feature. That’s what our product does; the problem that we solve is that we help you through that process. We help you communicate the strategy effectively to stakeholders in a way that they understand.
SA: You brought up the simplicity of tools. A lot of what we’re here talking about tonight is tools, right? Using tools to be effective as product managers, but sometimes, we don’t have the right tools.
We’re using Google Docs, or we’re using spreadsheets. So what are some of the specific challenges that you’ve seen arise in the context of roadmapping from not having the right process?
JS: Yeah, and just to be clear, I’m not plugging ProductPlan.
I think there are a lot of different ways of communicating the strategy. But I think some of the deficiencies that we caught on to early in our market validation process were that a lot of product managers, especially those who are new or maybe don’t have formal product management training, create a list of features — or worse, they have the backlog in their ticket tracking system — and they consider that to be the roadmap.
From our standpoint, and from the perspective of seasoned product managers that we spoke with early on, that’s not an effective way of communicating. You get lost in the weeds too easily.
You can’t see the forest for the trees. You aren’t able to take those details, especially those detailed stories, and roll them up into the big picture.
So that was a problem and a pain point that we caught on to really early. The product managers that have been around the block know how to do it. They know how to roll up features into the theme level, for example. They know how to say, okay we’re going to be implementing these features, and this is the reason why we’re doing this; this is strategically why it’s better for our customers, or better for the product, or better for the company.
SA: Can you share with us how ProductPlan goes about roadmapping. What is your process? Take us through it.
JS: Our internal process?
SA: Yeah, we want all your proprietary information.
JS: Sure, okay.
SA: And then we want to leverage it.
JS: Yeah, just so you know, we do eat our own dog food. We use our own product. We have our own product roadmap that communicates what we’re going to be doing over about the next six months or so, and it constantly updates.
I think some of you here work for larger companies, and that roadmapping process is probably longer term. The most common length of roadmap that we see when we’re talking to our customers is about a year.
But, ProductPlan has been around about four years, and we’re a smaller, more agile organization, so we tend to look over about the next six months. We just went through a planning process for 2017 and communicated that to all the folks who work for us. Everything was described in terms of bigger level themes.
SA: What’s an example of a theme at a big level?
JS: A theme might be an API.
For example, we know that integrations are important for our customers; getting data in and out of various systems is very important, and so we’re going to be developing an API. It’s in development, but we don’t know exactly what it’s going to look like at the end of 2017.
Saying exactly what we’re going to be building is not really the best way to go about it for a company like ours because we are constantly learning. Our roadmap should be constantly evolving. We should be working with our customers every day to really understand the pain that we’re solving.
So, that’s a little bit about our big-picture planning process. And then we also use our internal prioritization tool, we call it the Planning Board, and it’s basically a scoring matrix. We can put different items on the scoring matrix and look at them on value versus cost scale.
I think a lot of product managers use some sort of a framework or a scoring mechanism to rank items. How many of you use a spreadsheet?
SA: Show of hands for spreadsheets.
JS: Okay, I see a few.
SA: Get those sheepish hands up. It’s a good tool.
JS: There are a dozen different ways of doing this. There are a dozen different frameworks that you can use to prioritize, but most product managers go through, at least in their heads, this value versus cost matrix. Of course, you want to be developing the things that are highest value and lowest cost. That’s the low-hanging fruit.
So we use our product, which kind of bakes that into the process.
That’s a little bit about our internal process for prioritizing. But, I’ll tell you, we still don’t know at the end of the year exactly what we’re going to be building because it’s constantly evolving.
SA: It’s interesting, you brought up before that people rely on the backlog to sort of be “the thing”. This is something that comes up on the 100 PM podcast a lot — the challenge for product managers to weave between the strategic role, the the forward looking role, and then the more more tactical, execution based role. If you’re too much in the backlog, you’re only seeing as far out as what’s going to ship next week, next month, or whatever it is.
And as you mentioned, you’re agile, and you’re a smaller shop, so I’m curious about your thoughts for larger organizations. How do they avoid falling into that trap of being stuck in “well, this is what we planned” mode? I’ve talked to enterprise product managers who have roadmaps that have hooks into three and five years out. I’m like, I don’t even know what I’m doing for dinner tonight.
JS: I know, that boggles my mind.
SA: So what advice would you offer, or what can you say to enterprise-level product managers as a tips, I suppose, for staying agile in the planning process?
JS: A lot of product managers have so many things that they need to accomplish during the day — so many fires that they need to put out, a backlog that needs to be prioritized, an engineer standing at their desk asking clarification questions. There’s a tendency to fall into that tactical mode, and I’ve been guilty of it myself, where it’s really hard to come up for air.
I find that baking customer development and customer discovery into your daily process helps, and making sure that you’re continually engaging with customers. Whether that’s somebody scheduling a customer call on your behalf, or whether it’s you reaching out to customers or sitting in on calls with the customer success team or whoever usually engages with the customers. I think continually listening to that constant stream of feedback from the customers is the best way to get perspective.
And I know, it’s really hard. I think probably all of you have that fighting fires mentality. And that’s one of the wonderful things about being a product manager, you can have your fingers in so many different things. But it’s also a curse because everybody looks to you for the answer.
I think that keeping tabs on the customers is a really important thing. And I think another thing is letting go a little bit — not letting other people rely on you for the answer all the time. I’ve been in that mode myself in the past where you’re seen as the single point of truth for everything. Letting that go and letting dev teams make their own decisions, and if your corporate culture allows it, allowing the UX team to take on more responsibility — I think that’s another important thing that you can do.
By doing those things, you can bring it up a level and be a little more strategic about what you’re doing.
SA: You have been around for four years, do you consider yourself a start up still at this point?
JS: Yeah absolutely. I feel that even though we’re selling into enterprises — we have customers like Intuit using our products — we’re still very much a startup in two senses.
One is that we are very agile. We have the big picture plan of four big things we want to accomplish this year, but how we get there is still TBD, and the exact features that we build to get there are TBD.
I think the other thing is that Greg and I have a vision for the product. We have a long term vision for where this product needs to be, years down the road. There’s still more to do, there’s so much more to accomplish to fulfill that vision. And so from those perspectives, I think we’re definitely a startup.
SA: I’m curious how the landscape has changed? When you did come to market four years ago, were there other products like ProductPlan?
JS: Yeah, right about the time that we came on the scene some other products started to come out — products specifically for product managers. And since we’ve launched, there have been other products that do product roadmapping, and really that’s okay with me —
SA: You’re going to allow competitors? That’s generous.
JS: I’m okay with it; I’m not freaked out by any of it.
When we were validating GoToMeeting, there were 70 other online meeting products on the market already. With GoToMeeting, we were still able to disrupt the market with a product that was easier to use and had a unique pricing model that hadn’t yet been introduced into the marketplace.
I actually think that competition does so many things. It shows you that there is a market, for one, and it gives you an opportunity to differentiate. I think that with our company and our product, we have some unique differentiators, when you compare it to other products.
The landscape is changing, but in a very positive way. And most importantly, I think it’s changing a lot for product managers. How many product managers do we have here who have been at it for more than five years?
For those of you who’ve been in the industry for a while, you’ve seen the difference. You’ve seen all of these new products coming on the market, and you’ve seen organizations like General Assembly that are providing more education for product managers. I think that it’s a very positive thing for all of us when there’s more education, and when there are more tools and products available to help us do a better job.
The important things that we do aren’t managing backlogs or creating product roadmaps or things like that, but rather thinking strategically. It’s about engaging with customers and understanding customer pain. Those sorts of things are the important things. So anything that product managers have at their disposal to do a better job at being strategic, I think is a positive thing for the industry and for the occupation.
SA: And market research is so much a part of the role. It’s not that you come out into the market and then you can close your mind. There’s always someone lurking around the corner with the next disruptive idea.
I think the challenge as it pertains to roadmapping and product vision really is, on one hand, you want to make sure that you are staying current and that you are not being disrupted. And on the other hand, you want to make sure you are not being blown about by every wind. “Well, my competitor just built this feature, so we should build it too.”
How do you manage that? How do you differentiate yourselves or hold true to your vision despite whatever your competitors are doing?
JS: Yeah, that’s a great question because we’re faced with that challenge every day. A small example is that we are a product management software, and we think of ourselves as this strategic layer on top of project management software — products like Pivotal Tracker, for example, which manage the more detailed tasks that need to happen to develop products.
But we’re always asked for project management-oriented features, and so it takes a lot of willpower on our part to say no. We want to continue to maintain what we’re good at, which is visualizing the strategy, and we want to keep that focus. It’s kind of a constant battle for us to maintain that.
