Alex Swain is VP of Product Strategy at 10Pearls, a global product innovation and software development company. He started his career in content and media at The Weather Channel, where he managed the production and distribution of news and weather content on digital platforms. Alex then transitioned to production engineering at WebMD and media at IBM before moving to GreenSky, a point-of-sale lending solution. Most recently, he was VP of Product Strategy at Xtensifi, a boutique digital consulting and software development, before its acquisition by 10Pearls.
In our conversation, Alex talks about how the key to avoiding building a product that nobody will purchase is to always challenge assumptions, and how “you can love your market, your customers, and your opportunity, but you can’t love the solution.” He discusses the importance of failing fast and cheaply, as well as enabling your people to make those failures in order to find big successes. Alex also shares how he encourages a culture of healthy dissent by working to reduce anxiety within the organization.
I’ve been working in digital for about 20 years. I graduated from the Art Institute with a degree in digital content, which focused heavily on creating video, audio, and media. I immediately started working for the digital team at weather.com, where we were creating hundreds of forecasts every day specifically tailored for web and mobile. The first project I worked on was the implementation of an online video player, which was essentially the first cloud platform I ever had access to. I got an understanding of service-oriented architecture and content distribution.
At the time, there was a big need for syndicated video and they were selling it faster than we could even provide it. I saw an opportunity to solve something with technology and worked with our ops lead so that instead of us pushing video to partnerspeople, they would come to us via an MRSS feed that we were producing via our CMS. That was my real first dip into product discovery and product management. I became intrigued by the problems I could solve with technology and how I could make things faster, better, easier, cheaper, and scalable.
After weather.com, I got a job managing all of the video engineering and distribution technology for WebMD. They had a professional and a consumer side, and I became a bit of a product manager and solutions architect focused on internal systems. The advantage here is that you are right next to your users. You learn really fast to make people happy and to make things frictionless because there are immediate impacts if you don’t.
From there, I kept working in media and joined IBM, where I was doing live events and video-on-demand products — specifically for their sponsored events like the Masters, USGA, USTA, Roland-Garros, Chinese Open, etc. I then had a friend who was working for a fintech unicorn called GreenSky, and they had trouble maintaining brand integrity. He wanted me to come in and help build technology and processes that would help maintain that. I started as a content manager, and around nine months after I started, they built a product group. I was able to transition to being a product director on frontend applications.
After that, I jumped back into consulting and started working for my current boss at a place called Xtensifi. That brings me here. We were purchased by 10Pearls about 2.5 years ago.
Because I don’t necessarily have full visibility into a business, my first question is always about the opportunity and what the desired business outcome is. I usually start with a journey mapping exercise, where we’ll go through how their current process works from beginning to end and where they’re looking to change and improve things. That gives me a bigger picture of what I’m looking at from their business standpoint and what their value is. Often a lot of people come in with a solution, and the issue is that the solution may not necessarily be the answer. It may be what a customer asked for, but it may not address the problem.
Once we’ve gotten through that and understand that customer journey, that’s where we do a story mapping exercise and figure out what actually has to happen. What do we need to build? That story map gives us an actionable set of development stories. We’ll determine what the scope is going to be, what it’s going to cost effort-wise, and then the goal is to constrain the scope as much as possible to meet their budget and timeline.
Ice-T has a really good saying about this — a lesson will cost you pain or money, or sometimes both. Nothing is free and that includes learning. The core responsibility of our job is being responsible for investing the business’ money wisely and mitigating poor investments by killing bad ideas quickly and cheaply. The worst thing possible is to spend millions of dollars on an idea, have a go-to-market strategy, and then have it flop horribly and in the public eye.
That’s where empowering your teams to actually solve business outcomes versus the standard “checking boxes off a roadmap” tends to work out a lot better. You push them into a situation where they have to look at the problem from multiple angles and figure out how they can solve it. Test and validate all of your assumptions before you move forward with them.
Something like 75 percent of ideas fail. And for me, having a design background meant learning not to be afraid of critique and to not fall in love with things. That’s guided my philosophy that what I do may not be perfect and it may not be right, but if I learn something in that process, that may point me in the right direction. And if I can do that cheaply and not do it publicly, that’s the best thing for the company. You have to enable your organization and your people to make those failures in order to get those big successes.
The answer is it depends. If it’s a one-way door, you want to be really careful. One-way doors are situations where there’s no rollback — you’ve changed it and you’re stuck with it. I would like to make sure I have a good amount of data. You’re going to have to take the bet if you’re sure about it and if you’re getting a lot of pressure.
The timing depends on how soon you need to get to market, what the kind of competitive landscape looks like, and what the opportunity is. The opportunity may be, “There’s a big opportunity for this right now. In three to four months, it may be gone.” At that point, you have to set up the experiments using your best judgment in terms of how many people you have to test with, what the opportunity or time horizon is, and do a balance there.
We worked on a project for about a year. The person came to us initially and I said, “We want to do a month of design and discovery.” He said, “No, we need to just start development immediately.” I did what I could to limit exposure there and went with trying to not design too much of a custom interface — the plan was to get something out the door and get real feedback. That didn’t work out. He wanted to go all in. The challenge with being a consultant, as well as often in product organizations, is you don’t always get to say no. At a certain point, somebody’s going to just say, “Just do it” or they’ll find somebody else who will do it.
We worked for a year. Because discovery wasn’t done and we didn’t get to do much feasibility and viability testing, the cost to maintain the product was going to far outweigh the value it was going to bring. In that market, people could easily either do nothing about the problem or do a hack for free that would give them only 50 percent of the functionality, but zero cost. That’s what you’re up against a lot of times — your competition is that the user will do nothing. You’ll lose to do nothing probably 75 percent of the time.
In most organizations, failure of any kind is not an option. The culture doesn’t allow it and they judge people based on output instead of successful outcomes. This is a feature factory and it is extremely common — even in organizations that preach good product management. The pressure to deliver something always outweighs the desire to deliver actual value, and this creates a culture of low-value deliverables, anxiety, and apathy.
Simply put, happy people build better products. Your culture needs to encourage healthy dissent. People need to feel safe speaking out without being judged or reprimanded. It’s imperative that you reduce anxiety within your organization because as humans, anxiety is something we were meant to feel for fractions of a second to guide our fight or flight response. We’re not meant to be anxious for days or weeks on end. As a leader, you can reduce anxiety by setting clear expectations, providing actionable feedback often, and helping create a career path.
Leadership also needs to be committed to building this culture for it to succeed. I like the rule of disagreeing and committing. This means providing space for people to discuss solutions as a team and offer dissenting opinions, but, once a decision has been made, everyone agrees to commit to the chosen path, including leadership. Another tactic is encouraging direct, rapid feedback. This starts with leadership both giving and requesting candid feedback from employees regularly. This is genuine, actionable feedback that shows you care about the success of the team and the individual beyond their role and the organization.
Transparency goes a long way to building that trust as well. You don’t need to be transparent about everything you are planning, but you do need to provide a clear link between the opportunities you choose to focus on and the goals of the overall business.
It goes back to the inside-out problem where you have a lot of ideas coming from inside versus coming directly from customers. You can build something that’s beautiful and solves the problem, but if no one is willing to pay for it, download it, or use it, it’s useless. That’s the big issue — will someone pay for it?
This is where a lot of focus groups can run you in the wrong direction. People will say, “Oh yeah, this is great. I will totally pay for it.” If they leave the room and you say, “Great, give your credit card and I’ll send it,” they’re like, “No, absolutely not. I didn’t mean today, but sometime in the future.”
The key to avoiding that is always challenging assumptions. You can’t fall in love with your solution. You can love your market, you can love your customers, you can love your opportunity, but you can’t love the solution. It’s going to need to change and it may just need to be different than you expected to really get that value.
It’s a challenge. You have to walk that tightrope of, “I want to do the best thing for you, but at the same time, I don’t want you to walk away and go to my competitor who’s going to tell you they can build you whatever you want.” Using the journey mapping exercise, if I can convince them to at least invest a little bit upfront in planning a design so we can go through and do some discovery, that’s where I start. It requires taking a step back and looking at the overall big picture — at pain points, friction, and what people are trying to accomplish. They’re less focused on the small pieces and this enables you to have that conversation.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
The rise of AI agents undoubtedly signals a shift in how you interact with software. However, the demise of SaaS is far from inevitable.
Matt Moore talks about how new technology, such as AI, is changing healthcare for the better and improving patient outcomes.
This article delves into the two predominant statistical frameworks utilized in product A/B testing: Bayesian and frequentist methods.
Luc Lam shares what innovation looks like in words versus in execution within teams, and how to manage stakeholder expectations for each one.
Learn more →
