After a brief summer break I'm back with another Spotlight with Boston Product. Coming this time from the perspective of product management at an agency, I sat down with Stephen Roger, Product Strategist at Intrepid. We discussed vying for resources when you have a fixed budget, the motorboat versus sailboat method, and how little wins can sometimes make the biggest impact.
So what’s it like at Intrepid?
- The company was recently acquired by Accenture
- Product team includes PMs of all kinds — Product Managers, Product Strategists, and Project Managers
- Teams get to be newbies all the time, learning about all kinds of industries, tech, and business models.
Let’s start with a quick story…
Stephen: One of the apprentice apps that I teach is a meeting minutes app where you’d set your phone to listen to a meeting and with just a few buttons to record back in time a certain amount, say the last 60 seconds, only saving the bits you want. You then have just the most important five minutes worth of a discussion that lasted much longer.
Jenny: What do you mean by teach, who are you teaching?
Stephen: Around 2010 when everybody and their mother needed an app to do something, we had some trouble finding great people with experience in mobile. So we ended up creating an apprentice class. Now we have three a year, 20–30 people across many tracks over 12 weeks. In the first few weeks people design and build an app from scratch. The last few weeks of the apprenticeship you actually get to work on client project to really get a feel for what it’s like working on a real project.
To make these classes really good the product team has to maintain a backlog of product ideas that fit into certain criteria in terms of how much effort, the code being the right amount of intimidating, it has to hit certain learning objectives.
What’s funny is that while most everybody in the world thinks, “Oh, there are so many app ideas out there,” this is the only time in my life where I’ve been like, “Man, I could use some more ideas.” So we keep an internal backlog of all the potential apprentice apps we can teach. It keeps the product team here always looking for neat and fun things to teach.
A behind the scenes look at how the product team helps run the apprentice class. Now let’s look at the rest of Stephen’s world in product.
Stephen: I got into product working at a student loans start up, in customer and client service. I kept having to find workarounds in the product to satisfy customers and eventually discovered it was because the product and the processes themselves were broken. So I joined the product redesign team where we basically revisioned what the whole platform and user experience could be like from the ground up, then broke that into a bunch of different projects, sought new technologies, and kicked off a multi-year effort to redesign everything from the internal operational facing products to the customer facing products, to the client facing products.
Jenny: Were you actually able to take a step back and dream for a bit on how it could better?
Stephen: Yes, but I think that was more frustrating because we then had to find a stop gap for implementation. One of the best lessons learned was how to pick between having the vehicle we need to get our company from A to B running on the highway while also building a sweet new Tesla in the garage, and — what mostly happens — which is trying to tweak the engine while flying down the highway at 50 mph. In retrospect, I would’ve done the ‘work on the Tesla in the garage’ thing and spend minimal effort on the existing jalopy.
Stephen: I also got to experience how much of product management really is stakeholder management, as opposed to blue sky planning or implementation. By far the biggest thing is knowing how important is it to drive consensus before moving forward to build. At the last Product Breakfast, someone made a really great statement that if you’re doing stakeholder management well you don’t just get buy-in then walk away, you touch base every week or every month. Really specifically on that, not assuming that people know how the sausage gets made. Educating on what is essential to having them be in your corner and supportive.
An exercise I would do was to literally print out pieces of paper to represent our big projects and have stakeholders to validate each, then set the priority for each one. I would make them get up and move one item from position 1 to position 3 and then let all the stakeholders fight it out. It was really painful, but the only way to viscerally understand you can’t have three number ones.
Stephen: Today at Intrepid I’m a product strategist, which is an interesting term. It is largely a function of us being an agency as opposed to a product company. The way the role started out was in what we now call the motor boat model 🚤. For those projects we’d start with a discovery and design engagement, six to eight weeks, it sort of functioned like the start of a waterfall process. We’d try to identify the hero path and all the essential user stories, identify the app flow, what the look and feel is, most key wireframes all up front. Then everything after that is just building on the details, executing.
That worked really well in terms of—like a motor boat—you just point it where you want to go and surely you end up there. Once the projects got beyond that, larger in scope, that doesn’t really work and you begin to need to pivot along the way. That’s the sailboat model ⛵. We’re still going to point in a general direction but we’re going to have to tack, or pivot, based on external market factors, learnings from the data, the project, new priorities, and such.
Jenny: Sounds like the typical agile process. Start with a hypothesis, a bunch of assumptions, some data. Then you halfway through you learn new things that may be better. From that perspective it sounds pretty much the same as at a product company.
Stephen: A lot of what we do at the beginning of a project still looks like a motorboat. Lots of helping clients think about their roadmap so that we make sure we’re building the right foundation for the future. The hard part is eliciting the dependencies from clients, helping work through it because no matter how much we (product people) try to be experts at product, we’re not experts in our clients’ space; as opposed to a product company where the product person should know more about that space than anyone. We can never reach that point so we need to leverage our client’s knowledge and coach them through product decisions. Which is super fun because it means you get to learn a ton about a bunch of different things. Anything from how chemicals heat up and release a scent while we worked with Procter and Gamble to build an IoT Febreze device; or, working with PhDs in physical therapy while working with Saucony to build a running app. So you get to be a complete newbie at things over and over again.
Jenny: How would you describe the team culture and dynamic? Who do you work with, what are the roles each person plays?
Stephen: Here team sizes vary, but the composition is usually the same. We have a project manager too, which is a real blessing because it allows a product strategist like me to focus on the product. While we’re always paying attention to delivery it frees up more headspace.
The analogy I always make is while we’re both paying attention to the project management, you can do only one thing well. You can either allocate time to this urgent issue which might prevent us from being late on a launch or you can allocate time to interviewing customers or white boarding what the next feature should look like. Given that choice you’re always going allocate time to solving immediate issues. Urgent versus important.
Jenny: Gotta get out of the weeds sometimes.
Stephen: It’s great because the person whose core strength is not being the most organized person, lets the person who is better at it drive. I then act as a foil for my team by not having our project managers have to worry about what six months out looks like, and knowing that by the time we get there we’ll have a nicely groomed backlog where things are cohesive works really well.
Jenny: Looking at agency versus product life is there one thing that you wish you could merge together or share with the variety of PMs?
Always be an advocate of insight gathering, always.
Stephen: I think the way the business models are structured forces teams to operate very differently. One thing I would change is to naturally include more insights in the process. At a product company you don’t really have to sell the fact that user testing and analytics are important. In an agency, while clients understand that conceptually, it’s really hard to get them to pay you to design something, and then pay you to test the thing you designed, to then get feedback on why you — the expert — didn’t design something exactly the right way. And then pay you to course correct it. Even though you know it’s what’s best for the product, it’s hard from a relationship standpoint. And so often times that part of a project we have to do on the side, when you can squeeze it in.
Jenny: What have you done to show the value of that kind of insight gathering?
Stephen: Always be an advocate of insight gathering, always. Sometimes it takes a failure to show how much it’s worth. The other way is to build in small wins. For example when we really want to integrate—say—an advanced analytics software but don’t have time, we’ll do mini surveys with the teams, or we’ll run next door to Hubspot and take over their lunch tables to ask people questions.
Jenny: Guerilla usability!
Stephen: Low cost, small wins make the difference to having the conversation or not. Lay the groundwork early.
Jenny: What’s something your clients have taught you that has helped most along the way?
Stephen: Oh, easily it’s how much execution matters at the business level. What you do with a product and aligning it with a business model is far more important than how well or efficiently your design or development process works. So much of product success is how well you marshal your resources to support it. Whether it’s the marketing of it, how you align roll out with operations, or even how you leverage strategic partnerships to get the product where you want to be. Just building something awesome won’t necessarily make it successful.
So much of product success is how well you marshal your resources to support it.
Stephen: Another thing I’ve learned is how important it is to care. I really like people, I do really care about people. That comes about in a few ways. Some of it, simply, is that interesting things get done when people care, but it’s also important that people trust each other because that’s really when you see great results. You can push each other when nobody is stressed about who gets credit or who points fingers. When everyone cares, no one person’s opinion is best.