How to tell just the right story

In Boston Product’s PM Spotlight series, we chat with inspiring product managers in our community to learn about how the role varies across teams, industries, and business models. Over the next few sessions we’ll be meeting with product managers joining us as panelists and speakers this year at Unbox to give you a taste of what’s to come. Unbox is a full day event from Boston Product with the goal of elevating frontline product managers of Boston startups and fast-growing companies.

This week I joined Alec Pinkham, Senior Product Marketing Manager at AppNeta for a discussion about on walking the line between product and marketing, telling the right story — not one with fluffy details, and keeping people honest. The following is a recap of our chat.

So what’s it like at AppNeta?

  • Split between the marketing, sales and product teams Alec works with two other product managers and spends the majority of his time with sales and customer success teams.

Tools right at hand:

  • Asana: to keep tasks between teams
  • Jira: for back end development and for repurposing stories to be used in marketing content
  • Domo: a dashboard for product data and Salesforce integration

A path to product

Product is an interesting role to play; if you haven’t moved around to a few companies you can find yourself with either a really good definition of product or a really bad one. My path to product was a weird one. I started with degrees in mechanical engineering but realized that I wanted that to be a hobby not a job. I dove into software a bit during school and enjoyed it, so I found a company, ICONICS, that did software for automation of mechanical processes. I started doing quality assurance and software testing but planned path towards product management.

One of the reasons I took my current position at AppNeta was because the director of marketing at the time was an ex-engineer as well. By bringing knowledge from my previous roles at ICONICS being a product manager, from QA, some from mechanical processes, and marketing I’m able to carve out a unique niche as a technical Product Marketer today at AppNeta.

From my first role I moved to product because I was focused on the part of any feature or project very early on in the development cycle. I took part in deciding what we could do to improve the product, additions we could make, and ways to use the product differently. Being onsite with customers often, I also got a good feel of the pains they had and learned to have real empathy for their needs. Like most PMs, one of the major challenges I had to balance, sometimes ignore, were the many feature-creeper requests. Things that excited the sales and marketing teams, for example, often were in conflict with product gaps I observed in client interactions..

Harmony between teams comes from understanding (and measuring)

Sales and marketing are often the teams that lay out campaigns and go-to-market plans for a product. For a while I transitioned completely to marketing so that I could get involved with early planning and help decide what we’d eventually do with the product. Now as PMM with a more creative bent a lot of my time is spent arranging the words, the presentation, and the plans for the products we build. Here at AppNeta we don’t feel driven just by sales which is sometimes how product or marketing ends up. We’ve been able to work really well with our sales and marketing teams in ways that help us to not always be on the hunt for new markets or new prospects, broadening our offering. Instead we’re focused on solidifying the customers that we really want to sell to and defining which prospects we need to connect with. We do this by being very deliberate about the roles for each person here; from sales, marketing, to product, we decide who each person needs to talk with the most. It has made it super interesting because building a persona for something very specific is a lot easier when you can deep dive into your work with that persona and focus on the jobs they need to do. We can really focus on one thing a customer cares about at a time.

We’re focused on solidifying the customers that we really want to sell to and defining which prospects we really need to connect with.

Marketing is doing a good job of matching sales in having defined goals and metrics. I do feel that product marketing has a bit more to go in this regard as a field, and that’s something we’re working tackling here at AppNeta. Part of this is because the normal venn diagram puts Product Marketing between sales, product, and the customer team. But we’re of course tied to the marketing team too which means there is even more overlap between what I have to do with each team. I work with the customer team to get insights, I intake everything I can from product about what’s coming down the pipe, and then I work on content and lead gen for marketing. While all of these groups have fairly defined goals; for example sales cares about revenue and win/loss rates, as a PMM it’s harder because I’m not the only one who can drive conversion at any point. For example if I’m focused on content and how it affects sales you have to remember that content is a long-tail play where everything you would measure is extended by the sales cycle and anything else in the environment that may be happening.

My main focus is trying to figure out how to get measurability into product marketing. I’ve started in places like impact on revenue, though I find it’s still a bit nebulous because it involves so many people on my team so it’d be a little arrogant to think that I’m the only one contributing to that cause. Another is the marketing effect on win/loss rates, but first I need to start tracking dozens of metrics to get an idea of how the team factors in. So far I feel like as long as we keep in mind how each part of the team affects and is affected by one another these can be pretty good measures of progress. The hard part is picking a metric you know may be flawed and working to improve it, it’s been an iterative process for us.

We work with the mantra that “done is better than perfect” and as an agile organization in every capacity we’re constantly trying things out, running tests, so sometimes it’s hard to keep our metrics up with that. So right now I’m very focused on how we can make goals that are actionable, achievable, and then of course ones that we can track. This includes both external metrics like downloads and usage, but also internal metrics like what the sales team is consuming and specifically what they’re reading and sending to customers. You can’t just force teams to use a tool or follow a pattern to get metrics, you have to meet people at their behavior. So we’re trying out new processes to see what works best. Content is a huge part of product marketing so measuring how it’s used is immensely important which is why this task is so essential to get right.

You can’t just force teams to use a tool or follow a pattern to get metrics, you have to meet people at their behavior.

From the professional development perspective it’s fun because now I have the ownership of fixing these things, it’s just a matter of time and getting it done.

Keeping the shine on your product marketing

Today a lot of what we’re releasing is back end work and not necessarily client facing product updates. Since we’re in a phase of not doing tons of big, marketable launches I have to try different tricks to keep the customer and sales teams up to date with interesting facts they can give to their counterparts in business reviews. You can only say so many times that you “improved core technology.” Also unless it’s a lot better you kind of have to admit that you might’ve spent a sprint fixing bugs, but hey… they’re fixed now! I do everything I can to avoid writing release notes with just “it’s better,” instead I find ways of relating to customers and helping them see why they should care about this hard work. AppNeta is an interesting company to work for because our tech is quite differentiated and we have a lot of great stuff going on. From the marketing perspective I love being on this kind of product.

Every PM wants a product that has IP, that has differentiation, and for the PMM role you want these things because they bring value to your customer that no one else can offer and it gives you plenty of great things to talk about.

At the same time there is always a competitor who uses similar messaging as you even if their product can’t do exact the same thing. A challenge I like is finding those true differentiators and coming ahead. Part of why, even though I’m in product, I still do like marketing is just that — messaging makes the difference. If you can make yourself differentiated by both factors, product and marketing, then you actually have a good chance at succeeding. You have to be able to tell the right story and that’s why I’ve stayed with at least one foot in marketing. Its definitely the part where you get to use the most creativity and with a technical background I also have the utmost constraint on myself to make sure that I’m representing the product well, and not misrepresenting it in ways you often see companies do. Too often I’ve seen practices in sales and marketing where the product is misrepresented just to get a sale. From the marketing perspective if I’m working on a piece of content I have to make sure it’s right, that it’s telling a clear story. Because of that I’m always going back and forth with product to fact check, to confirm it makes sense, and that it’s not overstepping anything. You can easily get too fluffy with content–especially when it’s used for things like thought leadership because you’re trying to draw attention. In the long term we have a very technical audience with a very technical product; we cannot get away with fluffy forever.

One challenge I really enjoy is taking these stories we spend so much time getting just right, then reducing it down to just a few words to be used for lead gen–how can you describe such a technical product, all it does, what makes it stand out, in just a short phrase? That distillation is fun but sometimes can get really tricky.

Divvying up that Venn diagram

With where we are right now, probably 50% of my time is with sales and CSMs working on our sales enablement strategy. I spend a lot of time making sure they have what they need in order to take calls and entice people to take demos. Another 25% focuses on industry strategy which is many things; talking to product, to development, to sales engineers, and then even research just making sure I’m up on current technology. The goal here is to understand the ways that people in the industry are talking about things, to make sure I’m using a common language. It helps me keep a finger on the pulse of what customers care about. I’m always looking for ways to get people engaged so we need to be in the places where our customers are, talking about the things our customers are talking about. The last 25% is spent with internal processes and tactical work, the very intentional actions I take in in creating content, strategies, and campaigns.

Contributions from marketing to product

The biggest things I’ll contribute to product are large strategic initiatives and ideas. For example if the industry is moving in a new direction it’s on me and our team to make sure we’re talking about how to use our product to do this new job. Additionally to make sure we’ve made it super easy it find that job-to-be-done within our product. I’ll often package up data we have to tell a story about how a customer wants to use our tech in a new way, or how we may want to pursue a new idea. In that regard I work with product to figure out how best to address ideas and then how to make sure our customers know we offer it. Doing this has actually given me a bit of empathy for our product teams too. Having been in both roles I don’t want to be the person who comes in and demands that a thing be done, so I focus on telling a story and building a case for it so everyone understands. Then to keep the feedback loop open I’ll follow up with product to know when a particular feature or tech is coming down the pipe, when I should start producing content around it, and getting the sales teams ready with all the data they’ll need.

When it comes to data I find that Product teams often look at the high level of the whole product but then digs very deeply into optimizing one page at a time, making sure every link, every bit of content is just right. Whereas I’m looking for a broader view of the industry and how people in it are solving their problems and getting their information. It brings a different kind of insight to the mix.

Product still runs the roadmap

Most of the time real customer input will win out, so the product team takes precedence with roadmap planning. We still experience the common struggle that product managers have to deal with, when sales says that some large company wants to buy our software but won’t until it has a certain feature. Every once in awhile that will come along, but it doesn’t always take priority. Here we’ve been more willing to do that type of work for existing customers than for any new prospect. That’s not to say as a small but growing agile company we don’t still find ways to respond to the industry and serve our customer’s needs, we strive for a balance.

As the PMM I’ll also help the product team during certain phases of development like research, testing, or running beta programs with customers. I like this aspect of our relationship a lot because it’s great to be able to write and talk about products when I know they’ve been tested by customers. Being so close to the product team during these betas helps with creating great content as well. Especially since we have such a technical audience sometimes I even use stories that were in Jira for developers and adapt them into marketing content.

How many Ms? A note on PM+M relations

Understanding what each person’s focus and responsibilities are is super important to maintaining a good relationship, so clear responsibilities for a PMM and a PM need to be set depending on the company’s needs. It’s important to remember product marketing isn’t competing with product management, at least from the perspective of product knowledge. In marketing people are often billed as less technical or not as focused on the product but in reality, at AppNeta at least, we bring a different viewpoint to the product. Technicalities aside the whole idea is to introduce different viewpoints and these differences come together to tell a clear, compelling story to customers.


Defining Success for Your Product

A cozy breakfast this morning with our friends at Robin, hosted by Product Managers Emily True and Shanna Gregory, in their new office in Seaport. Robin makes office automation tools that making room booking a breeze—now their challenge is in defining what success looks like for a “choose your own adventure” product. With many implementation options, different customer types, and device specific toolsets, how does the team know who’s having success with the app, and what to offer next?

Have your own definition of success, but leave room for it to adapt

Early on a valuable measure of success for Robin was the number of meetings booked, but after observing actual meeting patterns and learning from real user scenarios, their CPO and co-founder Zach Dunn shared two stats that eventually changed their thinking:

  • 70% of people at companies book zero meetings, they just attend
  • Most meetings are recurring, so that only counts as one booking

Every company uses rooms differently, so you can’t count time spent in meeting. The question becomes: how do you gain visibility into the types of users you have and their specific cases? Paul Heayn, PM at Runkeeper, is a fan of the persona-based product development model. Where talking to customers, building the product with those personas in mind, then intentionally marketing to people who fall into that persona bucket, has driven success for his team. Paul sites an idea from Build Better Products which is to talk to customers often, until you know how they’re going to answer your questions.

Talk to customers until you know how they’re going to answer your questions.

Ways to slice and dice

For a product like Robin’s where there are multiple points of engagement and platforms to choose from including calendar plugins, mobile apps, and dedicated hardware outside conference rooms, do you let customers choose their own adventure? Or do you direct them to use a specific, limited toolset to focus on one core activity? To figure this out, Anna Perko from Hubspot considers the difference between the buyer and the end user. Many SaaS companies run a playbook of establishing customer advocates within your user base to drive adoption, enabling easier renewals and greater upsells.

A key product marketing task is to empower champions within a company to promote and teach other employees—a “train the trainer” approach.

Emily and the team face an interesting challenge in that they have two different gatekeepers to please—IT managers and office administrators.

Another option is to look at your needs from a device perspective. Are people on the go, using the product in real time or does it require more focused attention that someone planning would prefer to do at their desk? Why would customers adopt one over the other?

Instead of trying to offer all features across all devices, Wayfair’s Rachel D’Agostino suggests using device limitation as a way to educate users about new ways they can interact with the product.

Think of it as a teaching and learning opportunity.

Success for the product and success for the business

Brian Swartz from Catalant pointed out that for any new feature being considered, PMs have to keep an eye on the business goals. How does success at the product level brings success to the business? “As a user my problems are solved. I need a room, I found a room. What else do you need to solve?” If a Robin user only has their Outlook plugin installed and uses it to book all her meetings, does it matter if she has the mobile app too?

Sometimes when you have a hammer, everything looks like a nail. Maybe building new features or flows isn’t the solution. If end users don’t know about all the features a product offers, you may have a product marketing challenge on your hands. You need to understand the full path a user takes from trial to purchase to activation to renewal, and then identify your blind spots and your opportunities for improvement.

You can’t tell your users what to do. In fact, you’re better off with the opposite—having users tell you what to do. When you build a product, you’re the expert, and you know everything it can do. It’s tempting to want to share that knowledge with your users, but it’s important to remember that they’re hiring your product to do a specific job, and that’s what most important to them.

Don’t tell the customer what to do

This post was originally published for Boston Product. If you enjoyed reading this, please give us some 👏 and check us out.

How to advocate for insights

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.

Product Inertia Large and Small

In our second of Boston Product’s new series, the PM Spotlight, we spoke with Vesa Tormanen, CEO at Attriboost. We covered lessons from launching products into a crowded market, contrasts between start ups and mega corps, early roadmap rerouting, and how to walk the line between freemium and paid products.

Fun facts about Vesa:

  • Hails from Finland and studied computer science and his MBA there.
  • Led early product teams Nokia even pre-dotcom bubble.
  • Worked across the globe in India, Finland, and the US East and West Coast.

What it’s like at Attriboost:

  • Born out of the awesome tech at Fiksu
  • Small but growing team; 1 product manager, 5 developers, everything else borrowed and bootstrapped

Vesa has unique experience on product teams in the mid-90s at a powerhouse telecommunications company. Getting an early start on product management for software products. Let’s dive in:

Vesa Tormanen: Nokia was a pure product company which made it a really good school for product managers.

Jenny Miller: What about it made it such a good learning experience? Was the team structure different?

Vesa: It was a great product organization. Starting with the development team and a product team; we also had some people doing business development, and a support and deliveries organization. As an example: we created the first version of the product, a mobile TV app, many carriers wanted to try it out. We set up a trial and in no time we were able to distribute 50 of them all over the world. That’s the great thing about a huge company — you can perfect your pitch very quickly. You have a template on how to describe a product and you give that to the sales team, then you start getting customers all over the globe willing to try your product and give really good feedback. Trade show booths are another great place to hone your pitch.

That’s the polar opposite of what we’re doing now here at Attriboost. Here we’re starting ground up trying to build all those relationships. At a startup, there’s few meetings where you could get that much insight so quickly.

Jenny: What was one thing you could take advantage of at Nokia that is most different here at a smaller company?

Vesa: At a larger company, you don’t have to invent almost anything. There’s already a department that has defined a process for everything; hiring, building, everything. When we needed to divest a business there was already an M&A team with their own HR, legal, personnel to help get things done. There was always a group of leading experts who have already identified and defined for you a state of the art way of doing anything you need.

Jenny: Do you think you were able to move faster in that environment compared to a startup? Which is more agile?

Vesa: Inertia is different. In a big company, what inevitably happens is there are several organizations who start doing things which may appear to be very similar, and this creates organizational friction. One org might suggest another shouldn’t be working on a project because it falls in or outside of their domain. That can make things slow.

On the other hand, if you’re a startup with something new, the problem is that you may have a great new thing but no way to tell the world about it. In a big company there are always customers who are hungry to see the next thing from you.

Jenny: Traction versus growth then.

That’s a necessary precondition to being able to start new things; we’d observe for a while how our idea grows and if it doesn’t reach the necessary level then we’d kill it to make way for something with a bigger potential.

Vesa: Right. As a product company Nokia was always good at killing products too. That’s a necessary precondition to being able to start new things; we’d observe for a while how our idea grows and if it doesn’t reach the necessary level then we’d kill it to make way for something with a bigger potential. Not having resources tied up in sunset products made the company very fast at starting new.

Jenny: Killing off underperforming products or features is definitely a skill to learn. Let’s dig into Attriboost a little bit, tell me what it’s like here.

Vesa: We do mobile app ad tracking, a niche of a niche. There are a few million companies developing apps who need ways to get users by online marketing. With most mobile apps people are not spending thousands of dollars to use it, it’s maybe only a dollar here or there. Therefore you need a huge audience. You want to target very carefully and then measure immediately. That has given birth to this market for analytics solutions such as ours.

Jenny: Would you say Attriboost helps marketers learn how to target better or is it itself a way of finding the right customers to target?

Vesa: We tell our customers how well their advertising is doing in detail. Not just in terms of how many installs you’re getting but also how long users are staying in the app, whether they spend money. Then you’d look at traffic sources and targeting options, and compare which brings the best users and increase spending there.

Jenny: You mentioned a few data points there: installs, time in app, money spent. Those are important for your customers, what are some metrics that Attriboost measures? How do know if a particular product is successful, if a feature is working or not; when might you, as you said earlier, choose to kill a feature?

Vesa: We have just started, coming out of Fiksu. Fiksu already had the core technology but it was only available to its own customers using the service. When Fiksu was acquired by a private equity firm they wanted to see how this tech could be used individually. So, myself, Greg, and a small development team were tasked with making a business from our tracking and attribution analytics tech. This was just last summer. We started by looking at the competition, making an MVP, which we launched in December.

There are a few pretty big players doing a similar thing, but we’re going for low-end disruption. Offering a small set of features for free then, add some freemium features while trying to earn some revenue from things like also trading the anonymized application data.

Jenny: So what has it been like launching in a very saturated market?

Vesa: It’s just as hard as we thought. We have developed a self-serve platform, the only way you can really compete with a free offering is to stay really lean. We have run into many little issues around how to begin gaining traction; simple things like keeping your messaging out of spam folders, for example. We’re adding new users every day and already starting to think about wholesale opportunities, partnerships to access a lot of apps. While at the same time still trying to get one customer at a time.

I’ve never had a free offering before, I would have thought that when customers sign up for a free service they would understand it’s free; I underestimated how much people would still want to have discussions like those you would usually have about a paid product. What features they need, different options available, requirements.

Jenny: So how do you have these types of discussions with customers today? Are you communicating things like the roadmap or new features?

Vesa: We must communicate the roadmap and new directions. While I found it surprising that people would require features in order to sign up, it’s of course valuable because it tells us what the people want.

With a freemium model you have to think about where to put the line for paid features versus the free package. That’s a tough balance to strike because you can’t move everything to the paid service, because that is not what we’re marketing to users. We need to have our free service attractive enough without cannibalizing your paid market. It’s core on our value promise that whatever is free today will always be.

Jenny: Understanding what you do about launching in a crowded space, is there one lesson you’ve learned or an idea you can share?

Vesa: One thing we’ve done quite well is not just launch in a crowded space, we went into this to test a value proposition. Which is a different approach than what our competitors are doing. It lets us learn more about what customers want and what competitors can (or cannot) provide. It’s very important to not start by looking for your business case, but test an idea. Because even if your assumption turns out to be not correct, it’s still worth testing.

People who are serious about the product take time to ask a lot of questions.

One thing that would have been great to know was how critical every detail in our onboarding process is. Initially when we launched we were happy to see lots of people sign up but we soon began to see the same problem many apps have with abandonment. I thought that was mostly a consumer product issue, but it clearly also affects B2B as well. I thought if we made the barrier of entry as low as possible we could grow fast, turns out that the people who are serious about the product take time to ask a lot of questions.Those who aren’t sign up then abandon quickly. We’ve tried to send questionnaires to these users but they often don’t reply, so we need to work on how to get in touch, more feedback from these users.

We very quickly came to understand it was important to have dummy analytics data in the system for newly signed up users to communicate the value to the new users to better sell the product idea to the user — help them decide to go through the integration process.

The amount of motivation required to get a B2B customer to use a free tool after they signed up was surprising.

Jenny: Right, give customers a taste of what the product can do.

Vesa: The amount of motivation required to get a B2B customer to use a free tool after they signed up was surprising. So now we’re totally focused on doing improvements there. We had thought our roadmap was going to be new top line features, but we’ve spent a lot of time perfecting our ramp up to both activate and keep a larger portion of users.

Jenny: One more question, since you’re so familiar with Nokia. Are you going to buy the new 3310 with Snake?

Vesa: When they bring it to the US! I think that was brilliant marketing for them.

Boston Product’s new series, the PM Spotlight, we’ll be chatting with inspiring product managers in the Boston community to learn more about what it’s like being in product, how the role varies across industries and specialties, and hear stories from the road.


Getting Comfortable with Being Uncomfortable

This post is part of Boston Product Spotlight, a series from Boston Product, where I chat with inspiring product managers in the Boston community to learn about how the role varies across team, industries, and business models. Originally posted on Medium.

In our first session I spoke with Greg Achenbach, VP of Product at SnapApp. We covered what it’s like day to day on his team, his “anti-roadmap” of themes, and how he instills a customer-centric, data-driven view of the world among his team.

What’s it like at SnapApp?

  • SnapApp allows marketing teams to accelerate their growth by creating deeper, more engaging interactive experiences.
  • Greg oversees SnapApp’s product roadmap, strategy, and user experience. His team currently consists of two Product Managers and a Product Designer
  • Located in Back Bay, they prefer face-to-face communication over anything digital.
  • The office has an awesome hang out area that feels like a patio on a summer day.
  • Product managers spend about 60–70% of their time with engineering and the rest with customer success, marketing, and sales.

Jenny Miller: What is SnapApp doing to help marketers today?

Greg Achenbach: The goal of SnapApp is to unleash the potential in every marketer. To simplify things for other product folks, the SnapApp platform is essentially a content builder and analytics tool. The core of what we’re working on as a product team is SnapApp’s build experience. The PMs here take on a lot of other responsibilities too. It’s not just working with the engineers; there’s a lot of cross section with the customer success department, support, marketing, sales, and the executive teams.

Greg Achenbach, VP of Product at SnapApp

Jenny: Where does that put you on the classic PM Venn diagram of technical, UX, and business?

Greg: For us it’s not so much on the technical side, I tend to lean towards more customer-focused areas. My personal background is technical, but once I got out of college I decided that I didn’t really want to be an engineer. I spent a good part of my professional career in client facing roles so I was—before the term customer success was popular—more of a project manager doing a lot of onsite implementation for heavy, very complex enterprise software. I spent a good chunk of time out in front of clients until I hit my quota and wanted to go back into creating things. It’s important to me that there’s a deep sense of empathy for the client because I’ve been on the other side where you’re physically sitting in their office and they’re complaining about something the product doesn’t do. I like having a more customer centric view for the product team.

It’s important to me that there’s a deep sense of empathy for the client because I’ve been on the other side where you’re physically sitting in their office and they’re complaining about something the product doesn’t do.

Jenny: That’s such an important factor and one of the things that a really good product manager does well—acquiring and maintaining empathy for the customer. How do you bring that back to your team? Is there a process that you go through, a story that you tell that allows you share that experience?

Greg: There’s a bunch of different ways. The first is I personally try to get in front of clients as much as possible and I’m always pushing our PMs and designer to do the same. Whether it’s dedicated feedback sessions, usability testing, or just shadowing calls with sales. There are plenty of opportunities to do that throughout the day. Then it’s really about going back to what we’re trying to accomplish and making sure we’re actually still focused on the right problems. We’ve migrated towards the anti-roadmap camp for our planning, using more of a theme-based approach. When we’re digging into what a theme is, that’s the opportunity to go into the pain points or opportunities that we’ve learned from being on the front lines as much as possible and bring to light the problem to solve.

Jenny: You dropped a great term there, anti-roadmap. How did you start that approach, did you accidentally discover that you were following it versus an intentional shift?

Greg: This is coming from someone who’s both a PMP and a Scum Master in good standing: I don’t like process. Process has a good place but I’m more about just getting stuff done. I’ve tried to learn how to get it done via many different avenues in my career. The Agile methodologies—the core of why they were created—I really do believe in the flexibility and the fast moving nature. Trying to adhere more to that style of creating things has lead me to believe that creating a detailed plan for what we’re going to accomplish in a long period of time is just unrealistic.

There’s been plenty of opportunities we’ve encountered in the last few years here where being flexible has allowed us to take advantage of things a lot sooner, and I want to capitalize on that. So while we as a company have a vision as well as short- and long-term goals for the product, we want to remain flexible for opportunities as they arise and not be very rigid. I don’t always want to be saying, “We’ll get to that thing in six months,” just because it’s not on the roadmap. Also, as the person who has to create some visualization of a roadmap, I don’t want to have to spend time every week tweaking some new version of a Google Doc showing now this week we’re going to do this instead of that.

Jenny: Speaking of tweaking, if it’s not a roadmapping tool in your case, tell me a little bit about the PM stack. What do you guys use here day to day?

We want to track two sets of data. There’s the data on how people are using the product, then there’s data on how the content being created by the product is performing.

Greg: Well, we’re always trying new tools out. For communication, it’s Slack and email. Slack is a great tool but you also have to watch our for people being too reliant on it, leaning too much on Slack. Sometimes we have to force people to get out. Trello gets used for a couple different things. We use it to track client feedback and idea generation; we have a board set up so people can see what’s coming in. We also use it for a bit of the roadmap explanation, so internally people know what we’re working on now and what’s next. Jira is for working with the engineers. We use a combination of kanban and scrum-ish setups for that. I think those are the core things.

On the analytics side, this is a fun conversation that is always evolving. Our biggest attribute for analytics is actually a homegrown system because the nature of product gives us two tracks of data we care about. There’s the data on how people are using the product, then there’s data on how the content being created by the product is performing. We have this internal analytics report that is created every morning—that is more valuable to me than anything else. I’m also a huge advocate for Fullstory as both a support tool and for usability on the fly. It’s a quick and dirty way to watch how people are actually using your product. We also have Google Analytics for the stuff it does well.

Jenny: Speaking of data and analytics, one of the last Boston Product events was focused on being data driven. So tell me about some of the ways you guys use data to prove success of a product. Is it KPIs? What are the various metrics that you track?

Greg: We’ve got these evergreen statistics that go month to month, the core usage KPIs. We want to make sure people continue to get into the product and create content. That’s just a heartbeat for us. Then for every project we under take there will be success metrics underneath them. These help us make sure that we’re making the right decision as we implement a feature or improvement, how should we go about creating it, the timeframe for measuring it. Those differ quite a bit depending on what the nature of the project is. We look for metrics that answer questions. If it’s a usability improvement an example is: “Did the active use of the product get better?” One of the big things we look at is the amount of time people spent creating content. Others are:

  • If we introduce a bunch of usability changes that we expect reduce time, did it actually reduce the time?
  • If we introduce new functionality, how many people are using it, how quickly is it taking off?
  • Is the functionality we’re giving into the build experience impacting the performance of the app?

There is a whole variety of things we’ll look at depending on what the actual project is. There are no five simple KPIs for us because every theme of work has its own flavor of success.

Jenny: How do you share these metrics internally? What sort of communication tactics do you use to get people aligned?

Greg: The most effective way to work in general is just face-to-face. We’re all in the same building so it’s a lot easier to just walk over and have a conversation. That comes from the background of our last office which was one big room, there were no walls. For good and bad you hear and see what’s going on and we’ve tried to carry that on now that we’re in a bigger space. You might’ve noticed when you walk around we’ve tried to remove as many walls as allowed by the building managers. When we moved in here a year ago it was a very old school financial set up, tons of offices, wall spaces, very claustrophobic feeling. We tried to remove those physical barriers as much as possible because it’s a lot more useful and efficient to stand up and have a conversation with someone. That’s central to our culture here. Also the fact that the marketing team is a SnapApp customer itself, it’s a great internal resource for us to talk about ideas that we have. If we roll out a whole new UI update we can walk over and watch them use the product.

Jenny: What would you say is your superpower as a product manager?

My superpower as a PM is being grounded in reality with the problems that we’re trying to solve here at SnapApp.

Greg: Well I’ll go back to the idea of having empathy. Having worn those shoes, I have a tremendous amount of respect and empathy for anyone that has to be in the front lines as part of their job. It’s extremely rewarding being the person who is out in the wild making sure people are using the product that the company has created, but it’s also very stressful and can be very hard. If I have a superpower, it’s being grounded in reality and trying to solve a problem for clients. With technology today, you can build whatever you want, right? It’s easy to create really cool things very quickly, but if you’re not building them under the guise of being useful then it’s a waste of time.

Jenny: Now for the opposite: if there’s something that was your kryptonite, something that you’re working on trying to improve. What’s that for you?

Greg: I have a deep allergy to bullshit and all its different incarnations. For someone who’s got a tremendous amount of time in a classroom studying process — process for the sake of process has always just annoyed me. Process for the sake of solving problems I’m very much a fan of. I want to use my time as efficiently as possible so don’t mess around, don’t get in my way. But if you need something, just tell me what it is. This comes from my years of experience dealing with clients. Everyone has an agenda whether they realize it or not. Trying to spin things to get someone to be sympathetic towards you is just a waste of everyone’s time. Just be dead honest, tell me what you need, and let’s do it. If I have a kryptonite, it’s being stuck in meetings about meetings.

Jenny: What are you reading right now?

Greg: I tend to have a couple different books going on simultaneously. I just finished the Bruce Springsteen autobiography. I’m not necessarily a diehard Springsteen fan but I found the story fascinating. I read Shoe Dogs last year by Phil Knight, and that sent me down a rabbit hole of other autobiographies and how the concept of overnight success is so artificial. This weekend I picked up The Third Wave, Steve Case’s book. It’s part biography part prediction on the next wave of technical innovation. There are a lot of correlations to the early days of the internet where you could create anything but that thing needed to be plugged into everything, so we’re back into a deep sense of partnership and integration with everything.

Jenny: To wrap up, is there anything else that you want to share, some words of wisdom for the other PMs out there?

It’s okay not to know the answer. It’s okay to say, “Let me get back to you,” rather than force an immediate response.

Greg: A good one — It’s ok not to know the answer. That’s the biggest piece of advice I would give people. With the speed at which things move now there’s always the expectation of instant gratification. You don’t always know and it’s okay to say, “let me get back to you” rather than force an immediate response.

I don’t remember where the quote comes from, but this has been a big one for me in recent years: “In order to become successful you need to be comfortable being uncomfortable.” Like a lot of people in product, I’m naturally introverted. I’m only now getting comfortable being in front of other people and all the other fun communication that come with being a PM. Earlier in my career, a lot of that stuff was frightening. Where I’ve gotten the most personal growth and experience is by putting myself out there. I’ve taken that into a lot of other avenues professionally. If I feel like I’m not comfortable going into something, that’s how I grow.

Fail Fast, Learn Faster

Innovative teams of the most intelligent thinkers build products today at the speed of light. Some are winners and others are flops so what makes a team able to rebound from a failed release? If you ask many product managers today they’d tell you _fail fast_ but I'm not sold. 

Fail fast, early, and often
Teams embrace this concept and it’s been shown to work at times; yet, failing at any speed can only be half the plan if you want to stick around for more than a few failed releases. What makes continuous development, agile teams, and a fast paced environment productive is not failing fast, but rather learning from these trials even faster.

How rapid prototyping can lead to waste
With all the tools available today getting a working prototype out the door is something anyone can do and it can be done fast. Balsamiq is a classic for lo-res concepting, InVision is great for creating a clickable, interactive mock ups. There are plenty of others but before you chose any tool, or even decide to build something in code product owners should have clear goals and lessons they want to gain from the prototype in the first place. Leading with the goal to learn specific insights about your product, not to fail and try again later, will help define the focus of the prototype and inform the level of effort that should go into creating it. 

  • Define the core set of features for a release 
  • Identify areas that confuse or cause problems for users
  • Determine a clear user experience

These are all valid questions a prototype can help solve. Once you’ve established the goals you can select the format which will lead to the most valuable results. Then test! But instead of tossing out poor performing prototypes product owners must analyze these just a thoroughly as the winner. 
Learning why a prototype failed is equally valuable as understand what leads to success. 

  • What about the prototype displeased users?
    • Can you determine why? If not, retest. 
  • What was missing from the prototype? 
  • Why were uses looking for it? 
  • Why was it left out? Unsure, retest

Even these simple questions show that seeing failure in a prototype isn’t enough to make an informed decision. Get to the why and you’ll have a better idea of what should come next. Learn from your failures and you’ll start to fail less often.

Don't fail early and often. Prototype and learn, early and often.