Adapting and building products across different industries

What’s it really like building products across different organization types and sizes? How do you quickly adapt to industry changes?

Well, we thought we’d field some PLA community questions to Adrian Norville, Product Leader and Core Product Director at TextNow. Adrian has over a decade of experience in tech, spanning hardware, telecom, and SaaS. And he tackled a bunch of key questions to answer the above, and more.

Let’s dive in…

Q: How do you quickly adapt and get up to speed as a product leader in a new company?

A: A big part of getting up to speed in a new company is figuring out what other people do and what the networks of individuals and teams are. A big part of that is being able to observe people and just run into folks in the office. I've tried to take active steps in setting up meet-and-greets with as many people across the org as possible. Scheduling in time with existing PMs and developers is a great step as well to understand the product's current state and its history.

As a people manager, I'd focus on being available, actively checking in, and making introductions (focusing on exposing the unofficial networks and knowledge stores within the organization).

Q: What are the key differences going from working in product in startups vs big organizations?

A: It's an interesting switch to make. I've gone the other way over my career.

Though every company is a bit different, looking at a large corporate, I'd say the biggest differences are related to speed, risk tolerance, and communication.

Speed and risk tolerance are intertwined. Things tend to move slower, as these orgs generally have large user bases whose protection becomes one of the primary priorities, if not the #1. Working in that context, you can expect folks to always want a bit more data and to move slower in approving and rolling out new products and initiatives.

This all connects then to the communication piece. When I was at larger orgs, one thing I learned is that no decision-maker or their support team should be seeing your proposal, update or feature for the first time "in the room". You've got to spend a lot more time since you've got more folks involved in the decision-making, pre-presenting, and socializing of your ideas.

You have to be way more deliberate about your communication as a result; ensuring the right folks are involved vs the informal information flows that you might see at a smaller start-up.

Q: How do you assess your new product hires? What's your process for deciding whether the team needs expanding, rejigging or if you need to think about replacements?

A: That's a great question with quite a few pieces that intersect. When it comes to assessing product managers, I look at what I'd call the 2 pillars of product management -- practice (product management skills and aptitude) and domain knowledge (the industry, vertical, or technology in which the business or product operates). I find a person can usually get up to speed and perform well if they can generate value with one of those while learning or up-skilling on the other.

So even before interviewing, I like to figure out if I need a person who is going to be generating the most value on the PM practice side of things (agile stewardship, story writing, leading a team) or on the domain knowledge side of things (subject matter expertise, imparting a better understanding of the space to the org and team, etc). This assessment guides the interviewing and selection experience.

When it comes to determining when a team needs to expand, it comes down to the feedback I'm getting from the individuals on the team (are they overloaded now or getting close to it?) and the product and its roadmap -- where are we going, are we planning to add new features soon that will require lots of effort? Do we have the skillsets for what we need?

On growing/rejigging/replacing -- a product team is like a band and the product is the type of music you want to play. So, if we're making rock music, I'm likely not going to recruit a harpist. If we've got two guitarists I'm likely going to look for a drummer to compliment them and expand our sound. So for a product team, I may get a technical learning PM, another who's really focused on the UX, and another who's great at the business end of things. The goal is for them to cross-pollinate ideas and points of view, and support each other with their diverse skillsets.

Sometimes, you realize the PM you brought in doesn't fit the product and team you're looking to build, or you've pivoted and the value someone once brought isn't there anymore. That's when you look at replacing. But not before you see if they might fit somewhere else, or might be able to develop the needed skillset.

Q: What tools and resources have allowed you to work remotely as efficiently as if you were in the office?

A: I've had a great at-home setup for a few years so that made going 100% remote a smoother transition as I usually tailored my work setups to mirror my home office. That took one major piece of friction away. As far as tools go - Momentum has been great as well for tracking my to-do list and keeping me focused. I pick a few things each day and capture everything else in an Inbox list. At the start of each day, I pull the most important items from that list. Donut has been great too for creating some social interaction with colleagues.

Outside of that, I've been focused on ensuring my mental wellbeing has been taken care of. I try to do a mindfulness exercise at bedtime and also try to delineate between home and my workday -- it's not always clean, but it helps. It's impossible to be efficient if you're always working.

Q: Could you tell us more about how the product team is involved in the pricing plans, ensuring customer safety, and what’s the makeup of the product team itself?

A: At TextNow, pricing plans and customer safety are actually the responsibility of the product squads. We're organized around a few key pieces of the customer experience (wireless, growth, monetization, etc). Product at TextNow includes PM, PMM, and Design.

When it comes to technical focus vs sliding towards PMM, I'd say it really depends on the PM and the portfolio they're leading. Some of our PMs are former engineers or are working on very technical portfolios and so are deep in the technical weeds. Others, like growth, are more closely aligned with Product marketing.

Q: Any tips for ensuring agility within a larger organization with lots of red tape?

A: Agility, in the startup sense, is hard at a large org. The red tape is generally there to limit risk (or protect against a repeat occurrence of something bad). I think one thing is to try to work in the "white spaces" of the org and try to really think in the lean startup way. Can you validate without building or requiring investment? Try to get the blockers and concerns early and put something together to validate that they're covered.

Overall, it's the difference between an aircraft carrier and a speed boat. Get comfortable with the tools available and the way agility is defined in that context.

Q: Any general tips on stakeholder management within a big org?

Socialize and pre-sell your ideas -- once you get "in the room" every key person should be able to provide some feedback and feel a piece of ownership.
Understand the unofficial networks, who gets things done, and who has the ears of the decision-makers.
Prepare for politics. This may sound cynical, but it is the norm in many larger orgs. Visibility is limited and so folks in many cases will do what they can to be seen. Give people opportunities to be seen and take credit.

Q: Do you have any frameworks or methodologies that work well universally, or do you have to wildly adapt your approach across the board for different orgs?

A: I think one needs to adapt from organization to organization, but over the years I've developed a system based on Ian McAllister's framework. I use value/impact, risk, and effort to derive the scores for each initiative.

I make changes from organization to organization and I've had to abandon it once or twice. I always start with whatever system or methodology a team is using before trying something else. Change needs to be driven by need, not by desire or familiarity.

Q: What's your process for feature prioritization at TextNow? How do you sift through and decide where you can deliver the most value?

A: I would try to create a more structured approach to collecting information on customer needs and try to collate them and transform them into actionable items.

A platform like Intercom will skew things towards the vocal users and in most cases won't give you easily identifiable leads towards what the user base will see lots of value from.

Sit with your customers regularly to do interviews, some of these can be purely discovery focused (why do you use this product, how? what problem does it solve for you, or value does it create. Just observe them using it). These will help you generate ideas as to how it can be improved. Other's can be around specific ideas you have and involve testing those.

If you have a hunch or data that warrants further investigation, test it out. Spin up an experiment that will test it quickly and cheaply. You aren't looking for a home run, just provide directional guidance on whether to investigate further or try something else. Painted door experiments are great for this.

A: I would separate SEO and content marketing. SEO is a must-have if you expect to acquire customers through the web or other digital means (I'll lump App store optimization in with SEO).

Put in the effort for SEO but don't break the bank and don't lose focus on your product. SEO can't fix a bad product. And remember that most SEO pros out there are guessing at what they're doing. No one knows how Google's algorithm works. For content marketing, it really depends on your product and the market you're serving.

Q: At TextNow do you have product management and product marketing as two distinct functions/departments?

A: At TextNow, there are two distinct roles but like with any organization, there is overlap. There's no real clear, hard and fast delineation between product management and product marketing so a good PM can handle some product marketing work but also knows when a PMM should take the lead.

Product Marketers also need to be able to think from the product management perspective so that they can provide valuable input on product development.