Introduction

SM: Let me start by asking you about the context at Currencycloud in 2016 when you were in the ‘Build’ phase. Can you give us a sense of the situation?

SB: At that time we’d achieved “real” Product Market Fit (PMF) in one customer segment - our web platform for FX Brokers. We were also winning early adopters in a small number of adjacent customer segments like prepaid card issuers with our API product. Things were going well. We were getting a lot of inbound enquiries. But it wasn’t all plain sailing.

SM: Why? What was the main challenge?

SB: There were two. First, we had to find a similar vein of “real” sustainable PMF with our APIs and to sell into multiple customer segments with this proposition. Second, we had to figure out how to prioritize building out a rounded ‘whole product’ API solution that gave us the best chance of winning in multiple segments. To put it simply: we were figuring out on the fly who else to build for and how we could get that built, all while scaling our platform and company.

SM: It sounds like everything got a lot more complex.

Complexity increases

SB: That’s exactly what happened. Complexity increases hugely at this point and it can get a little overwhelming. Think about it: your buyers are probably changing from the ‘Start’ phase and you’ve likely moved up the value chain to target more conservative buyers who aren’t as risk averse and innovative as early adopters. 

SM: You also mentioned selling into multiple segments.

SB: Correct. Sustaining revenue growth requires you to build for, and sell into, multiple customer segments. Now, for some growth firms, this may not be a huge deal. Segments may overlap widely and the solution you build may be good enough to meet a wide variety of needs. However, that’s often not the case. Rather than going a mile wide and an inch deep, you have to do the opposite and go deeper in terms of the build and the needs you’re solving. That can be a hard balancing act. We certainly found it challenging.

SM: I remember at that time, you were also exploring entering new markets, right?

SB: We were. Not only were we exploring new customer segments in our existing markets, we were also trying to penetrate a whole new market in North America. Looking back, it felt like we’d reached the next level of a computer game and that building product became a whole lot harder.

SM: How did you cope with that? What is your main bit of advice to builders in this phase?

Prioritization is critical

SB: This advice sounds pat, but it’s nevertheless true: you can’t do everything. You can’t be all things to all people. You have to prioritize and focus. That means saying no. A lot. It means facing head on the HIPPO effect (i.e. the highest paid person’s opinion) which is often wrong. 

SM: How did you do this? What did you use to help you prioritize and focus?

SB: I know there’s some controversy about frameworks and their overuse, but I love them! I fully endorse the George Box quote that all models are wrong but some are useful. And Product prioritization is one of those areas where it’s extremely useful. So, at this stage, if you haven’t already done it, I recommend you introduce a prioritization framework. There are loads to choose from. None are perfect. All have flaws. We used Weighted Shortest Job First (WSJF), but you could use RICE or a bespoke Weighted Scorecard. To be honest, it doesn’t matter which one you choose. What’s important is that you make product prioritization decisions and trade-offs transparently, using that framework, with a wide group of stakeholders. And that the assumptions underpinning those decisions are transparent.

SM: Why is it more crucial at this stage to be clear about trade-offs?

SB: I don’t know if it’s necessarily more crucial at this stage; it’s just more difficult and there are loads more trade-offs. You’ve gone from one backlog feeding multiple product-engineering teams to multiple backlogs. The game’s different. Look, people want prioritization to be tidy, quantitative and algorithmic. It’s not. It’s messy and qualitative. And that’s okay. What’s more important is that you’re explicit about trade-offs and that you’re decisive.

SM: You mentioned the move to multiple product-engineering teams with their own backlogs. Why is that such a notable marker for you?

SB: I don’t know if it was specific to Currencycloud, but this was the point at which every trade-off seemed to become harder and more unpalatable. Saying no became notably harder at this point in our growth. It was also the point at which we became a lot more intentional about some aspects of culture and organizational design. We were deliberate about hardwiring autonomy, mastery and purpose into our small cross-functional teams.

Everything needs to be transparent

SM: Let’s come back to something you said earlier. Why are you such a big advocate of transparency?

SB: One of the superpowers of startups is their ability to make quick decisions and build fast. In my opinion, transparency is the single most important factor in supporting fast decisions and product development. What do your people want, really? They want to understand the business context and to have a stake in decisions. If you’re transparent about why you’re prioritizing a certain product or segment over another, you avoid all of the arguments, bureaucracy and backsliding that plague other organizations. And, crucially, I’m not just talking about Product and Engineering here. It goes wider than that.

SM: Where else is this important?

SB: I’m thinking here about collaborating with the Go-To Market (GTM) functions of Sales and Marketing. Transparency about which segments you’re building for and why goes a long way. If there’s misalignment and secrecy, small pockets of dysfunction may set in. You can get Product Managers ignoring real signals from Customer Success or New Business teams. Or the opposite is also true: you can get Sales going rogue and promising the world to prospects and clients. Either way, transparency is the route away from these errors.

Different waves of PMF

SM: Moving on to GTM, you’ve spoken with me before about PMF going in waves. Talk to us a little bit about that and why it’s an important concept.

SB: I think it’s hugely important overall for everyone to be on the same page about what PMF is and what it isn’t. It’s not a one and done event. Alignment between customer needs, proposition and distribution channels can never be done. Yes, you have to find PMF to double your ARR year-on-year. But the search for PMF is never done. That’s why I like to think about it coming in waves. While it’s not definitive, Currencycloud has had at least three waves of PMF to get to $100m ARR. In the first wave we had our web platform for FX Brokers. In the second wave we had our API for prepaid card and wallet providers. And in the third wave we had a whole product solution for digital native banks. Finding and riding these waves was hard. And there’s no playbook to guide you.

SM: So how did you do it?

SB: Well, let’s start with the fact that these waves of PMF didn’t come out of a lab, staffed with geniuses, who knew exactly what they were doing and who didn’t need any luck. There’s so much nonsense spoken about fast growing companies. Look, when I joined in 2016 the company had already found PMF in one segment, so I was blessed. The founders were a great combination of smart and lucky. Subsequent waves of PMF were found using very conventional customer development techniques. We spoke a lot to customers about their problems and needs; about how they buy and make decisions. We followed Marty Cagan’s invaluable advice to dig into the four different product risks - value, feasibility, viability and usability. We tried things out and failed. But one thing we always obsessed about was trying to solve customer problems.

Mistakes

SM: You mentioned failure there. As you know, I love to talk about mistakes so other people can avoid them. What would you say were your biggest mistakes during the ‘Build’ phase?

SB: Wow, where do I even start? I think the first mistake was trying to build products for too many customer segments in parallel. I also think we hedged more than we needed to and were always looking to triangulate; to satisfy the needs of as many customers as possible. In hindsight, we could’ve focused harder. Related to that, we were often too much of a slave to the Left Hemisphere of our brains. We were too rational and didn’t make enough space for gut feels and bets. By all means go get the data quickly and push back on colleagues who don’t do the work to back up their gut. However, there is often a signal in their intuitions. Miss that at your peril.

SM: What about something more directly related to Product Management?

SB: As I’ve gotten older I’ve learnt to appreciate that product management isn’t just about shipping software and collaborating closely with colleagues in engineering. At the beginning I neglected Sales and Marketing more than I should’ve. It takes a village to raise a child and it takes a village to develop PMF. Propositions and positioning are crucial. Sales Enablement is crucial. I know that now. Another mistake that’s closely related to this is ignoring that customer needs are never just met by software. There are ‘whole product’ elements that are just as crucial, such as documentation and where in the distribution journey prospects are introduced to your product.

SM: Any others before we wrap-up?

SB: The last one that comes to mind was being too slow and conservative to make team and organizational design decisions to support building new products for the larger segments of the future. I think I lost some time through being a little bit too conservative. However, we’re talking about people here and I’ll never take those sorts of decisions lightly, even now.