Depending on your demographic group, profession, and personal goals, you must be either nodding your head in approval or thinking how insane this person must be to sacrifice a significant chunk of his (and his colleagues') personal life to ship Internet Explorer - probably the world's most hated browser.

I've been thinking about this a lot, and I feel that he's both insane and right. After all, where's the right balance between work and life, when the two so often overlap?

I think this discussion fits into a wider theme, which is that of building up versus burning out.

Building up

A sense of shared community and the feeling of building something meaningful and lasting are amongst the most powerful feelings lucky people will experience in their lifetime. From attending church choir to making art, society and accomplishment are key for our well-being once our basic needs are fulfilled.

For a lot of people, however, it's not really quite straightforward to find either - and that's where jobs often come to the rescue. Modern companies have realized that a sense of shared purpose is key to accomplishing their mission (and therefore meet shareholders' goals) - so they will try to create this feeling amongst their employees.

That's a trick (and not a cheap one), but it's not inherently wrong. When people join mission-oriented companies, they'll usually buy into the community - and by extension, into the mission. And sure, there is a fine line between great company culture and goals, and a cult-like mission - but in general, finding a place to work at that straddles this line (on either side) is a stroke of luck and - for many - a revelation.

"we're building something meaningful, and we're doing it together" is one of the most powerful feelings you can instill into a high-performing team. In fact, I'd argue it's one of the core duties as a senior PM level and above; but the feeling needs to be channeled for the right projects and products. It cannot be a blanket feeling that encompasses anything that the company is doing; it can't be a cult.

Occasionally, projects will come along that warrant this fervor. I can imagine that the project this tweet references (building Internet Explorer over at Microsoft) felt like something worth building, and sacrificing their personal balance, for a lot of people. That's because it hits the three core pillars of a "building up" product:

• 🆕 it is something new: not an iteration of something that exists, but something that truly has the greenfield potential of being the starting point of a lasting legacy
• ⏩ it has a sense of urgency: if it's not built on time by the team, someone else will get there.
• 🆙 people growing on it will experience exponential growth: working on the product will let people develop skills much faster, that will let them grow in their life and career.

By definition then, a "building up" product must be successful - or at least create a lasting legacy with its failure (think General Magic or the Buran shuttle), it must be a sprint, not a marathon - as one cannot sustain a fake sense of urgency forever, and it must end with opportunity and recognition for the team.

I think that's where Hadi's tweet falls short of expectations. Internet Explorer did create a lasting legacy, but a negative one (both because of its anti-competitive practices and because it was, throughout its career, the worst browser to work with); the sense of urgency lasted for years (Hadi himself says "it was a marathon, not a sprint"), and not everyone on the team got the recognition or grew their skills in the direction they wanted.

That's when a "building up" project turns into a "burning out" project.

Burning out

Burnout is a hot topic, especially during this pandemic; and yet I feel it's largely misunderstood in its complexity. In my opinion, burnout is often conflated with exhaustion; and yet, the two are not the same.

Exhaustion is when someone is overworked for weeks, months, sometimes years at a time. They no longer have the time or will to focus on other things; and work becomes their core occupation, around which they mold their life. Eventually, everyone breaks - that's when exhaustion kicks in. Much like a runner collapsing just after the finish line, these people still want to do their job well; they just can't because they are too tired. Unlike burn-outs, the cure is easy: prolonged rest, often a new job, or a change of scenery, and that's pretty much it.

Burnout is a lot more complicated; but if I had to put a label on it, I'd say it's "loving a project more than the project loves you". It's not a function of effort, it's a function of results - and it is much more dangerous and complex than simple exhaustion.

Products that are not "building up" products, but still get hyped up as if they were, are the ones that usually lead multiple people in your team straight into a burnout. If you promise the "new and exciting success", the "speed" and the "reward", you better be sure that all three components are present. People will then make a conscious choice to work deliberately and intensively towards achieving that common goals.

I have been on two products so far that were truly transformative and had a "building up" momentum going on; they were (and still are) the highlights of my career so far; they created amazing friendships at work and - lo and behold - still allowed me to keep my hobbies, my passion, and a reasonable work-life balance. It is possible to work on "building-up" projects without burning out, and they are a transformative experience.

But that's not what Hadi is describing there - and that's why people are reacting negatively to the tweet. Pretty much everyone has direct or indirect experience with a product that gets oversold. We buy the story and pour heart and soul into it; yet the product doesn't seem to fulfill its promises.

Maybe it's a product that's not been built on solid ground and never had real opportunities; or maybe it's been planned beyond the limits of feasibility or resources, so deadlines keep slipping and the amount of work and effort must increase to keep up with increasingly shaky and multi-layered schedules.

Eventually you wake up one day questioning "what am I doing with my life" - and yet you are too tangled with the promises and sunk costs of these crazy cult-like projects. What can you do then if not burning out?

Burning out on these projects, then, is kind of a "circuit breaker" of the unconscious mind, protecting body and souls from the damages of wasting one's life energy on the wrong things. But unlike exhaustion, rest won't be enough: after one has been burned on this type of product, the risk is that cynicism and lack of trust will characterize the rest of his or her career. Recovery takes time - so better not to lead people down this path in the first place.

High performance products

Ultimately, it's not hard to create a strong team. All it takes is matching the expectations with the reality of a team. Not every project can be a "building up" project; not every product a flagship product. Most teams do both innovation and rote maintenance; things that are truly important, and things that are "ok if we fail"; things that are mission critical and things that can wait.

Having a good grip on which is which, both as a leader and as a person will ensure that the rare, beautiful communal effort that is a true "building up" product will be recognized as such. People will believe that something great is being built; they will pour their energy into it and accomplish unheard-of leaps in both the space of possibilities and their own career.

But if you know 🆕 the product isn't transformative, ⏩ it cannot be done as a sprint, or 🆙 it won't bear enough learnings and rewards for the people that pour their energies to it; then it's just better not to lie to yourself and to your colleagues.

Some products are not a higher calling, or a mission - they are just plain work; and recognizing them as such will protect everyone from burning out.

18 months later, I'm a PM working in a team that's 6 hours ahead of me. I have never met most of my colleagues. And yet, we've managed to keep productivity high and keep many ambitious projects on track while working from home.

When I finally got vaccinated in June 2021, I decided to go the extra mile: ditch my beautiful home up North and become a full fledged digital nomad. I would do what my working class parents could only dream of before the age of Zoom and cheap 4G connectivity: I would enjoy the beauty of travel and discovery while keeping a high-performance job that pays for my bill and gives me stability and purpose. My boss was supportive, my vaccine passport ready: I booked a one-way ticket, and left.

On both sides of the productivity continuum - from the crazy 10x programmer to the low-rank social media influencer - you'll hear a lot about the virtues of remote working. The Covid pandemic is a large-scale experiment that has demonstrated that companies can survive and thrive while fully remote. And for many people this is a dream come true: no longer bound to the office and its menial politics, water cooler talk, drab cubicles and mind-numbing routine, they are finally free to travel and enjoy life as it's supposed to be: work to live, instead of live to work.

Personally, I lasted less than 8 weeks before I finally caved and booked a flight back to our office. For me, it just didn't work.

As it turns out, I am not alone. There's a lot of commentary on the internet about how great remote work is, but in the real world, most of my friends and colleagues enjoy the flexibility, but dislike pretty much everything else about it. When adding the digital nomad component into it, the total package really does fall short of expectations and - at least for me - becomes a completely different experience than what aspirational work-while-travelling articles paint.

As to the why, I think it comes down to four pillars - the people, the productivity, the creativity, and the reality of it.

The people

I have been lucky enough to study at some very good universities, work at brilliant startups, and later on brilliant products at two pre-IPO companies (Adyen and Wise). In all these places I met many inspiring people that were smart, motivated, and well positioned to show up every day with experience and passion.

I'm trying not to generalize here, but as a digital nomad I met a whole lot of people, none of which were that inspiring at all. I can think of many people I have worked with -either in the office or from home - that I'd love to start a venture with; but I wouldn't do that with any of the people I met while digital nomading. Not a single one.

I have moved to new cities before and met really interesting people (and even lifelong friends) through online communities such as Meetup and Reddit. But following the digital nomad infrastructure, I converged to destinations that are very popular amongst a certain type of travelling professionals: young, largely freelancing, largely working on social media-related things. And all I found were communities I had nothing in common with.

Working for me (and many people I know) is about forging long term connections - it's more than networking; rather, it's a funnel to meet like-minded, hopefully brilliant people, that can show you the world in a new light. Nomad life, on the other hand, is fast and fleeting - something that definitely reflects in the personality and careers of the people I met.

Maybe, if digital nomadism becomes more than a pandemic-driven need, infrastructure will evolve to allow companies to replicate the office experience in many different hubs. Or maybe, as more traditional career workers start leaving the office in droves, there will be less tiktok influencers and more brilliant people building sustainable, impactful businesses at your local WeWork.

Until then, I suspect the average digital nomad in Lisbon or Phuket is optimizing for a different life than the one me and many of my friends and acquantainces are personally looking for.

The productivity

I generally would think of myself as a productive person. I love my job, but I also have plenty of hobbies outside of it; and it's very rare that wake up feeling like doing nothing all day.

Even when I'm at the office, I actively enjoy what I do - so you'll rarely find me at the watercooler chatting, or idly checking my Instagram while waiting for a document to upload. Instead, I try to keep my work life balance sharply tuned, and accomplish as much as I can in the hours of work I have - so I can go home and do all the other interesting things I like afterwards. Most of my colleagues are like me in this regard.

When I transitioned from office to remote work, my productivity stayed largely unchanged: some tasks, like brainstorming or aligning the team for a certain task, got harder; some others, like writing spec or doing deep work became easier to do without a noisy office environment.

Adding the digital nomad element into the mix, however, had a significant impact on my productivity. You see, if you travel while working you will have to plan for a lot of different contingencies: fast internet, a quiet place to stay, you luggage, your lunch, your flight tickets, your passport, your covid test - and what are we doing after work? And who are we meeting? And what are we cooking? And do we have salt? And what are the five things to do on a Wednesday in Porto? And...

Our brain is bad at multitasking. Digital nomading takes all of the negative factors of office working, and cranks them up to 11, by removing all of the comforts that come with a complimentary office or your own Work From Home rig.

Once again, I'm trying not to generalize - and this is my personal opinion and in no way a single truth - but I'm struggling to see how anyone doing my job can argue that we could be more productive if we'd do it from a different location every week. There is absolutely nothing about travelling through exotic location that incentivizes you to do your job better: instead, it adds a lot of cognitive load to your limited brainpower; new, unpredictable and constant interruptions; and of course even more way to get distracted.

Let's face it: humans are naturally procrastinating primates, and if we have to choose between a delicious espresso and croissant followed by a bath in the afternoon sun versus chasing that horrible supplier once again or sending a 200-lines excel sheet full with detailed information, we all know what we'd rather be doing.

There's a higher amount of trust built into remote working, by definition: we trust people to do their job without constant supervision, and I absolutely support that.

But for the productivity argument we really need to split 'remote working' and 'digital nomading'; I personally think it's possible to work from home or another trusted flexible environment and achieve a high level of productivity, but I think it's extremely challenging and, in the long run, impossible to do so while travelling around as if you were on holiday.

When I started staying in the same place for longer, I managed to bring my productivity back to a level I was happy with; even then, I never managed to shake the feeling I was doing two job at once: that of a traveller, or an explorer; and the one I'm paid for, as a senior product manager at Wise. Ultimately, I decided to cut the experience short and go back home; my productivity instantly went back to regular levels.

The creativity

Many of the best ideas I've ever had at work come from two avenues: spontaneous sparring with my colleagues, and deep empathy with my customers.

Exchanging ideas with colleagues is already difficult when working remotely: it's virtually impossible to schedule a '45 minutes Zoom brainstorming session', and those of us who tried it know it's a largely futile effort. That's the one thing, in my opinion, that work from home cannot provide when compared to the in-person experience.

But surprisingly enough, I found empathy to be by far the most unattainable of the two while travelling as a digital nomad.

This made little sense: I am the product manager for a card product geared towards travelers, and I was dogfooding my own product - by using the Wise card as my only way of paying across Europe - all the while visiting beautiful and inspiring locations. Why were the ideas not flowing?

I suspect the answer to this has to do with the creative bandwidth of your brain, and how it's spent. I suspect I was spending all of my brain energy by taking in new ideas and experiences, and I didn't have enough time and capacity left to distill them into actionable insights and actually solid product ideas and developments.

We often imagine artists, travelers, writers and photographers producing their best work while on the road. But most of Hemingway's books were written in his bedroom in Key West; Kerouac's "On The Road" was compiled in New York, and Steve McCurry develops the picture he took in his travels back at his studio in Manhattan. Travelling can be inspirational - but the insights come on the way home.

I don't think there can be deep, meaningful work done while plotting a trip from one destination to the other. On the opposite: I felt the mental drain of deciding my next sight to visit or thing to do took away time and energy from my self-reflection and deep, meaningful work both on a professional level and with regards to my hobbies.

The more I traveled without recharging, the more unable I felt to tackle uncertainty and meaningful problems at work; and even on a personal level, the quality and quantity of my passion projects declined more and more.

I'm sure there are some jobs that benefit from a continuous stream of experiences to be consumed in parallel to rote, routine work; or to be regurgitated towards a group of followers without much processing at all. As product work goes, I think it would be very challenging for a product manager to be on the road 365 days a year and still tackle his or her work at the level I've seen people do at the office or while working from home.

The reality

Ultimately, the dream of working while travelling has a very strong appeal to people like me that can't afford to not work, but also have the curiosity, empathy, and interest to enjoy getting to know different places and cultures. For years I dreamt of it, and thanks to a supportive company and boss, a good track record at work, and a strong pandemic-driven shock in workplace habits I was finally able to try it out.

I know now that the idea of combining work and travel and living as a digital nomad is not as straightforward or as enjoyable as it seems on paper. I feel a lot of people writing about 'the future of work' today are too often writing in hypotheticals, praising the edgy choice, but doing so from the comfort of their office. I also feel they might be jumping to conclusions too early about what the average worker really wants from their job.

Sure enough, this experience really showed me the reason why I do the job that I do, with the passion and intensity and effort that I put into it. It's not for the salary - that I could comfortably draw while travelling with much lower effort or contribution; no, it's because I enjoy being with brilliant and driven colleagues (the people), building sustainable and impactful things, stretching my capabilities every day (the productivity), and come up with solutions that are thoughtful and innovative (the creativity).

Switching from office work to working from home, I found that I was still able to do those things - sometimes less, sometimes more effectively. I enjoyed the flexibility and I feel a hybrid working model is something that would work for a lot of jobs out there.

But when I decided to become a digital nomad, and try and solve complex product problems from a rickety plastic table on a sunny beach - that's when I realized there are important advantages to the traditional structure of work. Digital nomadism, at least for me, really fell short on all the core parameters that render work enjoyable and meaningful.

I think it is quite counterproductive for the debate to conflate 'working from home' with 'digital nomadism'. The former simply moves the office from a physical location downtown into your living room, bedroom or (if you're lucky) studio. The latter completely removes the things that make working great, and delivers an experience that's neither here not there.

For this reason, I'd be wary of anyone that pitches you digital nomadism as the future of work, or working from home as a threat to productivity. As usual, it's best to take such sweeping claims with a pinch of salt, and instead think about what the future of your work looks like - and why it matters.

Content programming will resume from the 23rd of August onwards.

A common theme for people like me who started their career at ramen-profitable startups and then ended up working at progressively larger places - all the way to the large technology multinationals I work for now - is a certain degree of romanticism towards the early days of working at a startup.

"It was so much easy to make things", we muse forgetting about unpaid salaries and neurotic founders. We think about how projects were shipped effortlessly and product after product produced and pivoted at a startup nimble enough to turn on a dime - something lost now we have to work at 1000-sized companies.

The bad news first: it is indeed more complicated to ship products at larger companies. The stakes are generally bigger, multiple other teams need to be involved, and generally speaking the more 'cooks' there are in the product kitchen, the more crazy surprises will turn up before release.

The good news is the main reason that team don't ship, is because they are bad teams rather than teams at large companies. But getting your product to the finish line is, like anything once it scales, a more methodical effort at larger companies. A framework that has helped me a lot in keeping the ball rolling regardless of how large the company I work at is, is looking at my team as a startup on three key verticals: hiring, budgeting/planning, and distributing your product to users.

🤝 Hiring

Some managers like the financial sense of security a large company offers, and tend to get pretty liberal when planning their team's growth. And of course at some particularly feudal corporates someone's standing might be determined by the amount of people he or she manages. To no one's surprise, teams often grow exponentially at large corporates.

Before writing that job description or firing out a sprawling headcount growth plan, however, you should think long and hard about whether doubling the size of your team will help you ship twice as fast.

Imagine you're building your startup: what you're looking for are people who:

• ✅ are diverse in thought and abilities from what's currently in the team: will they bring something new to the table the startup currently misses?
• ✅ are irreplaceable and bring pivotal skills: do I really need this person to ship or drive this product I have in mind?
• ✅ have a proven track record or, for entry-level roles, the drive and hunger to really make it work for the startup.

This all seems obvious, but at large corporations I've often seen teams open up headcount just because they could, and team managers follow the opposite growth direction than if they'd had skin in the game.

I've written about excellent teams before, but this is a topic that's very close to my heart - so here's some of the things you'll see at bad corporations but not at the successful startups you and I fondly remember working at:

• 🚫 Hiring people for 'cultural fit',
• 🚫 having friends, referrals, colleagues or others join your team because you enjoy hanging out with them (also common at lifestyle startups, those usually end up nowhere though)
• 🚫 hiring people before you need them; also known as the curse of 'hire them and we'll find them something to do'.
• 🚫 hiring people for redundancy, and generally 🚫 getting more of the same profile in your team 'just in case'

This all happens a lot when you lose track of how your team needs to growth - and that inevitably leads to sluggish roadmaps and s**t product launches. Don't be like that. Your goal in a team should be the same as that of a founder: make every hire count.

💰 Budgeting and planning

Imagine sinking millions into a product that is not generating any revenue at all, and has a sizeable team slowly working on it day after day. The only explanation for such a violation of the laws of economics is that the product is made by a team at a large corporation that is profitable for other reasons. Millions wasted on a product that isn't going anywhere is nothing more than a rounding error on the company's balance sheet, and the product will continue existing despite not having a reason to.

The company funding this abomination might not care at all, but you should: working in a team like this usually is a good recipe for either burnout, career suicide, or boring internal retirement. And as you'd imagine, it's very rare for successful products to emerge from these teams.

Some of the most successful teams I've worked at instead treat the team or at most the product vertical as a singular business unit that is responsible for its own cost and revenue.

This doesn't mean the product needs to be bootstrapped or profitable from day one: it's reasonable to invest resources in a product that is showing growth and potential - much like a VC or seed fund would do. What's not reasonable is keeping a product that isn't worth its development cost on life support forever.

An important note for finance-oriented readers: this is 🚫 not zero based budgeting. Much like a startup might need capital burn and a sizeable runway to take off, there are justified cases where a team might be unable to justify expenses. And leaning on ZBB usually leads managers to simply game metrics to justify their quarterly expenditures.

What I've personally seen working is a three-pronged approach:

• ✅ financial transparency: everyone in the team and those collaborating with it should -at a minimum - be able to list the primary expenses and cost drivers for the product, as well as the current revenue, growth rate and expected net profits. This really isn't rocket science and helps the team keep their eyes on the prize. Every single startup I've worked at did this on a regular basis during all hands. It's radical, but it works.
• ✅ target planning: the product leads (usually a dev lead, PM lead and sales lead) should be able to align on the next relevant milestones for the product, the deals in the pipeline, which promises are feasible, and how big an opportunity they represent.
  Every startup I've worked at does this out of need - but it's surprisingly common at large corporates to only involve sales once the product is built, or to think development is nothing more than an execution engine. That's a no-no.
• ✅ career accountability: at functioning companies people should feel empowered to make big bets and promise huge things. If they succeed, they should be rewarded for it. If they consistently fail to deliver on their lofty promises, they should be recognized as a snake oil salesman and reassigned to a role that fits them better, preferably outside the company.
  Lack of accountability kills productivity at large companies.

Having understood a product's financial upside and costs, having clear growth targets and a startup-wide plan to get there, and holding people accountable with their investments is something that happens regularly at the best startups I've seen in my career. Why should this not work at your team? Operate like a corporation, but budget like a startup.

🚚 Users and distribution

One of the most important questions you might face at a startup is: 'who's this product for?'. This is a valid question that usually consists of two pieces: why your users should care about - and hopefully pay for - your product, and how will they know your product exists.

For a startup, these are challenging question: marketing is expensive, our world is flooded with advertising, and breakthrough products that 'sell themselves' are very hard to invent anymore without significant capital and R&D.

Having existing customers is an inherent advantage of large corporates - yet something that they reliably fail to exploit. When you start or inherit a product line at an existing company, you should instead ask yourself the same questions: why do my users care, and how do I reach them - with a focus on the second one.

You see, if you're working at a multinational, chances are the company already solved these questions with a core product that users wanted. That might be search for Google, shopping for Amazon, an OS for Microsoft and Apple, and so on.
These companies capitalized on their early success to launch more product lines - but most importantly, they used their existing distribution network to get their new products to a critical mass stage.

You should treat your team as a startup, and understand which needs your product is solving for your users, and how you can leverage the products or services those users are already paying you for, cater to them and upsell them to your next big idea. The principle is the same - just on a different scale and with a much smaller effort than at a cash-strapped startup.

• ✅ ask yourself what unsolved problems your users have, and you'll end up naturally expanding into unaddressed business lines your company is positioned to exploit - just what a disruptive startup will do if you wait for long enough...
• ✅ think about how to reach your existing users, for instance by using company events to upsell them on new products, making your product discoverable from their existing integrations, or enticing them with discounts on what they currently use, in exchange for them trying out your new product, and you'll have access to a market many times bigger than that of your startup competitors.

Startup teams have a hard time letting users know their product exist. But corporate teams have a hard time understanding what their users want from the product being built, and struggle to recapture the early days' magic. That's what people mean when they say "we're too big" or "we can't innovate anymore". Maybe - but your existing customers are a treasure, and can be leveraged as your distribution network. Target them like a startup, and distribute to them like a corporation.

🎁 Wrapping up

If you used to work at a startup and are now at a large company, chances are you miss the speed and innovation of your early days. But it's possible to recapture the magic, if you just start looking at your team as a startup in and of itself. That means:

• Hire sparingly - not to build redundancy, but to expand the team with diverse candidates with unique skills. Make every hire count.
• Plan and budget like a startup: transparency on cost and revenue, openly plan for targets with sales and engineering like you would at a 5-people startup, and hold yourself and your colleagues accountable
• Understand your market like a startup would - but also understand that your market might already exist as the existing users of your company, which can be reached effectively and at no cost. This is something a regular startup can only dream of.

The products you ship will be worth the effort.

When starting a product at any large-ish company you will need to present a global overview of how much your product will cost and how much revenue it will generate in a given amount of time (typically the first year of operation).

In my personal opinion, that is a reductive way of looking at your product's ROI - and one that doesn't capture the complexity of who will need to maintain it afterwards. I've seen plenty of high performing teams being crushed by the duty of maintaining their flagship product - and becoming unable to innovate.

A useful mental model to see whether your brand new idea is going to drag down a team like that - and mitigate that risk - is to look at your product and determine whether it's a plane, or a rocket.

• ✈️ A Plane product takes effort to get up in the air - and the team celebrates once it takes off. But the reality is that if you want to keep flying your plane past its maiden flight, you'll need ground operations, a flight crew, and refuel stops. Without that, the team will keep scrambling forever to keep the plane flying.
• 🚀 A Rocket product also takes effort to get up in the air - generally more so than a plane product. But once it gets out of the atmosphere and into orbit, it will stay there with minimal energy expenditure for a very long time - without generating significant maintenance costs for you, and leaving the rocket team able to innovate and work on the next launch.

To make this more tangible, we can look at Stripe - a company which has innovated plenty in the last few years, but has also had to scale up their workforce significantly and is known in the sector for occasional ruthless crunches. Which of their products are planes - and which are rockets?

✈️ A classic plane product: Stripe's payment methods

Imagine we're trying to start a payment processor. If we're based in the West, we'll most likely go with VISA, Mastercard and American Express first. Once those are done, the strategic next step is branching out to local payment methods - stuff like bank redirects, local wallets, and alternative schemes.

Now here's the kicker: any new payment method is not a rocket product - but a plane product. Every single payment method requires bespoke integration, expanding or upskilling the operations team, new settlement flows, new monitoring and infra tooling - those are fixed and variable costs that will remain with the product for the remaining of its lifecycle.

Once the product has launched, the maximum utility for the end customer is achieved: the only thing that can happen now is scaling: more customers, more transactions. Many PMs will let marketing take care of that, and move on to the next payment method. But tossing more and more payment methods onto the team's platter without a credible scaling strategy will lead to an inflection point where the team spends more time maintaining existing methods and putting out fires, than building something new for the customer. The plane becomes too heavy to fly again.

That's not to say plane products can't be successful or profitable. But you need to capture this complexity when deciding what to build - and not stop at a single 'additional volume estimate' that doesn't take into account the team growth and expenditure needed to keep the plane flying forever.

🚀 A rocket product: Sigma

So what's a good example of a rocket product? To me, that would be another of Stripe's offering - Sigma. Sigma is, at its core, an SQL dashboard layer that allows customers to query their own transactions - and get insights based on their payments without having to build reporting or data storage on their end.

This product must have been a difficult one to launch: aggregating many different payment methods and products built at a different point in time into a single data lake, ensuring PCI compliance, security and access segregation by allowing customers to only query their data, and of course the fact the payment data can now be scrutinized by the customer directly (prompting plenty of customer support contacts) are just some of the many challenges the team no doubt had to solve.

But now the product is out there, its maintenance cost does not scale linearly with the amount of customers. This is a fully in-house product, does not depend on external integrations, and is by and large feature-complete: there is no need to add graphs, machine learning, or analytics notification since the customer knows exactly what to expect from Sigma: a no-frills SQL dashboard for querying data they don't have the ability or capacity to store.

This rocket product is in orbit, and will stay useful and profitable with limited effort from the team.

🛸 A spaceplane: Stripe Tax

Does that mean that any product that requires integration or maintenance is by itself a plane product?

Let's take a look at the recently launched Stripe Tax, which allows customers to easily embed and report VAT rates on their checkout page. A seemingly simple endeavor that is complicated by constantly changing - and regionally granular - VAT and tax amount.

Stripe built this no doubt with the help of a significant contingent of for-hire lawyers, plenty of research, and their strategic acquisition of TaxJar. They will need to maintain the product forever: as VAT rates changes, so will the underlying product - and keeping track of variations over time and region will be a constant chore the team needs to fulfill.

Stripe managed to turn this plane into a rocket in two steps:

1. First, they changed their pricing model. TaxJar - which they acquired - is priced, like most robo-tax advisors on a monthly or yearly fee. Kind of like your tax accountant.
   
   But Stripe Tax charges you per sale: every time a tax is calculated, you'll pay Stripe an outrageous 0.5% of the total transaction amount, an amount they're keeping for themselves and not paying to any middleman like you would for an additional payment method. As maintenance cost scale with usage, so does revenue.
   
2. Second, if any region is underperforming, Stripe can simply pull the plug on coverage for that region with 30 days' notice - something that is impossible to do with payment methods.
   
3. Third, a large part of the issue with plane products is the liability they generate for the team running them -  things like fraud, timely payouts, or SLAs are what keep plane product teams awake at night.
   
   Stripe completely writes off any and all liability for this product, neutralizing one of the largest risks for this product. If the team is unable to update the service to include the latest VAT changes, that's no biggie: the customer is liable for this in the end.
   

Stripe does not represent or warrant that the Stripe Tax Services will enable you to fulfill your obligations under applicable Law, including with respect to taxes. Stripe is not liable for any tax calculations generated by the Stripe Tax Services. You are solely responsible for your compliance with applicable Law

While this makes this product arguably a better deal for Stripe than it is for their customers, there's no denying here that they have managed to defuse two of the largest risk of plane products - and turned them into rockets.

In short:

• 💰 They worked on pricing to ensure that revenues would automatically grow at a faster rate than maintenance costs: plane tickets are prized to cover the cost of fuel.
• 🌎 They segmented their product to allow them to turn on or off features and regions at any time (either with a termination clause or the Beta moniker): only the most profitable routes are flown
• 🥔 They removed liability ensuring neither the customer or other departments can force the team to maintain the product they created. Airlines are liable for customer injury, but rockets are not - that's how you can tell them apart. And while passing the hot potato to the customer is not a good strategy, if the liabilities being shifted are reasonable, it's a good way to protect your team.

Building rockets - or turning plane into spaceplanes - is a good thing to do if you plan to keep shipping year after year.

Let's get the obvious out of the way: understanding the sector you operate into and the customers you're selling to is an essential skill as a PM: without it, originating new products and product features becomes a game of luck rather than a repeatable challenge.

Understanding customers generally is achieved in one of three ways: by passively acquiring knowledge and experience of your sector, by looking at the hard data (either existing product metrics, or external data for prospective products). or by talking to them directly (informally, through structured customer interviews, or through surveys),

The first two are pretty self-explanatory, and there is plenty of information online on how to tackle metric-driven product development. Today I want to focus on the last notion: the idea that you can distill product insights by listening to your customers telling you what they want.

This is possible - at least in theory - but there's three important caveats I've seen PMs fall into over and over again:

🃏 Selection Bias

(Self-)selection bias is a very common concept in experimental statistics: it's the assumption that the group of volunteers giving you feedback is actually significantly different from the general population that your trial (on in our case, our product) targets.

If you like economics and want to see a mathematical outline of what selection bias brings to homogeneous populations, you can take a look at Roy's Model: a classical toy model with two outcomes - in our case "give feedback" and "don't give feedback" - who are mathematically demonstrated to be solely driven by how strongly the customer feels about our product, rather than about how good the product itself is.

What this means in a practical context, is that only the customers who are truly polarized about the product will be bothered enough to let you know, either in surveys or social media. This polarization will be exacerbated either in the positive or negative direction depending on the feedback channel: intuitively, people will be more negative on anonymous social media, and more forgiving in small-group, face to face interviews. More importantly, smaller grievances about the product will be easily missed (especially if people have larger critique or praise), which paradoxically makes customer feedback very ineffective in creating a polished product.

The largest problem that selection bias brings, however, is that customers will naturally focus on giving feedback about the product they have experienced, rather than the product you're aiming to build. This makes it very difficult to focus on the future possibilities and the roadmap ahead: especially during early stages of product development, listening to too much feedback will lead your team into an endless optimization loop, where the product is endlessly scrutinized, but does not move organically to the next step.

I know this is a handful, so let me recap: selection bias means your customers will 'self-select', and the majority of feedback will come the customers who feel the strongest about your product (love/hate). This means:

• feedback will be overly negative or overly positive (depending on the feedback medium) compared to the actual state of your product
• small issues will be missed: it's likely you'll hear about the glaring flaws you already knew of, rather than the small grievances you missed
• especially for early feedback, since the customer only sees your current version of the product - rather than the final one - you risk getting stuck in an optimization loop, instead of building towards v 1.0

🙉 Selective listening

This one's short and sweet: as a PM, you probably have a strong vision of your product, and talk on the regular with other teams to sell your vision and get people onboard.

It is very tempting then to take all of your customers' feedback, skim it, and cherry pick the items that back your vision up. "You see guys? I thought we should do A rather than B, and the majority of customers agree".

The majority? That's very hard to conclude from a small sample of customer feedback - especially given the previously mentioned self-selection bias. Yet, the temptation will always be there. Don't be that guy/girl: you should be extra careful when listening to customer feedback to record every single point of feedback - even those that don't support your vision of the product.

Especially for doomed, cursed products that should never have been developed, customer feedback is a powerful tool to understand when it's time to pull the plug. I would even argue feedback is at its most powerful when it allows you to see that there's just no way your product can do what you dreamed of.

If you catch your colleagues doing 'selective listening' of their customers' feedback, call them out on it. Feedback should never be weaponized, and it should never be used as a validation of your pre-conceived idea of the product. If anything, it should be used as a safeguard to avoid building useless things.

🤖 Automate your feedback review

This one is very personal. I see plenty of PMs having great results with parsing complex survey and market overviews into planning documents and ideas. Some people just have very good empathy skills with their customers and are able to distill many hours of interviews down to actionable product development milestones.

But I can't, so I let computers do the hard work of parsing my customer feedback for me - in three easy steps.

First, I collect all of the general customer feedback I have from my social and marketing teams. In larger organizations, there's probably dedicated teams that parse all of this data already and put it in a nicely formatted database.

If not, you can probably start by scraping some comments (preferably automatically) from Twitter and other social networks. Even better, just organize a session with your customers and have the write out all of the feedback they have about your product.

Since you don't need your customers to help you put together a full narrative, but rather you just want them to jot down all of their thoughts in an unstructured manner, the chances of them stopping at the most obvious flaws - or of them being nice to you (see the previous points) will be much lower.

Second, you can take all of this data and categorize it. There are some crazy souls out there doing this by hand or with Excel - please don't. And don't use heuristics or keywords (like 'good' or 'bad') to assign scores: that's primitive and inaccurate.

Instead, you can use sentiment analysis to give a positivity score to each line of feedback - even with no-code solutions like Google Sheets. Me, I generally spin up a Jupyter Notebook with Spacy, use TextBlob for sentiment analysis (which works straight out of the box), assign some categories manually and then use a Spacy classifier to bucket the remaining items of customer's feedback into the categories I defined, automatically.

Third I distill this data into N buckets, that represent all of the strengths and all of the weaknesses of my product. I compare this ranking with my personal ranking of what my strength and weaknesses are for my vision of the product: if my view and my customer's view match, then we're on the right track. If there are large discrepancies, I go back to the drawing board since it's clear I'm missing something.

Especially if you're working with social media feedback of an evolving product, or NPS comments from your customers, you can keep doing this on a rolling basis once you've set up a data pipeline. This is truly a superpower that helps you steer products in the right direction without wasting weeks in survey feedback planning and collection.

Of course, if you don't feel comfortable with this flow and have no analyst at your company that can help you out in setting this up, you can always invest into a license for customer feedback analysis tools like Chattermill, Retently or AskNicely (but there's plenty more, and I have no preference - they all do the same thing).

For a monthly fee, you will get a nice interface like this:

That will help you quickly sort out your customer's feedback into valuable buckets that can inspire and drive your product growth.

♻️ Wrapping up

To recap, I think it is crucial for good product managers to listen to their customers to understand how their product is faring. You can do so either by analyzing product metrics, by building direct experience in a given sector, or by directing asking for customer feedback.

If you go down this route, though, you'll need to make sure:

• 🃏 that self-selection bias doesn't give you extremely polarized customers with feedback that lacks details and leads you to premature optimization
• 🙉 that you don't selectively listen only to the feedback that validates your product vision: on the contrary, use the feedback to know when to pull the plug

Finally, it is not necessary to spend days or weeks trawling through customer feedback (or limit the amount of feedback collected): you can use 🤖 your computer to automatically score and classify the feedback you received - using either simple no-code methods like google sheets with natural language API, open source libraries like Spacy and TextBlob, or dedicated analysis tools like Chattermill.

Knowing how to collect and use customer feedback is a superpower. Hope this post helps you in leveraging it for your next product!

So how did our work life fare? On one hand, this forced remote working experiment has managed to prove that our existent infrastructure is enough to keep productivity from zeroing out without people meeting in person or at the office. On the other hand, companies large and small will now have to figure out a new normal as remote working stops being a 'necessary evil'.

My colleagues' opinion has been evenly split between those who thoroughly enjoyed the benefits of working from home (shorter commutes, less office distractions, increased flexibility in work-hours and work patterns, time for deep work, and no mandatory socialization to name a few), and those who yearn to go back to the office (where they can get free snacks and food, a dedicated place to work, casual and effortless interactions with their colleagues, and a better separation of 'home' and 'work' time). For me, it's a combination of both.

But that's not what I want to talk about. No, in this post I want to shine a spotlight on a category of people for which this working-from-home experiment has been uniquely and unequivocally s**t: the juniors, the interns, and generally all of the people at the very beginning of their career.

For people who started their career just before or during the pandemic (that's around 8 million kids in Europe and about as many in the US, so not a negligible number), working from home has three distinctive disadvantages - that are too often absent from the discussions we're having about the future of remote working.

🙈 Learning by doing

The first and most obvious disadvantage our 'work from home grads' are facing is the lack of continuous guidance.

Having no 24/7 mentorship 'on standby', ready to jump in whenever there's a question, a doubt or an opportunity to learn something means that remote grads cannot improve their way of working just by sitting side-by-side with more experienced colleagues.

During the pandemic I have worked both at Adyen and at Wise - two companies that have good and amazing internal documentation respectively, beautiful learning and training hubs, a very supportive environment where mistakes are tolerated and exploration is rewarded, and ample resources in terms of time, headcount and money to train their fresh hires. Both companies were also distributed onto multiple locations before the pandemic.

I can only imagine how horrible it must be for grads joining one-office companies, smaller startups, legacy companies where processes are codified into roles and institutional knowledge rather than written documentation, and companies where business rules are not backed by software rules.

Proponents of remote working argue that it is not necessary to sit next to a physical person to 'soak up' their knowledge - that structured learning sessions and modern tools like digital whiteboarding or team-wide conference calls are good enough substitutes of the good old 'shadow me for a week' method.

I completely disagree. Costly mistakes and important lessons are learned at the most unexpected times: there is no way to catch a fresh graduate hire doing something stupid on a conference call, or to teach them something 'off the cuff' remotely when the need arises.

Even more worryingly, because of remote working, fresh grads are less able to experiment inside the company, and are exposed to a smaller subset of the complex rules and processes that makes a product. Even with all the care and support in the world, this new way of working inherently encourages a task-driven way of working; one that leads fresh graduates to perform within the lines we paint for them in the internal documentation and daily or weekly Zoom catch-ups, rather than learn holistically about whatever we're building.

A controversial statement: I would personally argue that one year of remote working is worth just a few months of physical experience for people at the beginning of their career. This opportunity cost is very real, and will be especially devastating if we enter a recession anytime soon - as junior hires will not have matured sufficient experience to compete with their mid-career peers in a shrinking job market.

🚀 Cruising, not accelerating.

Many of the proponents of remote working like to point to the fact that, almost two years into this experiment, many companies have managed to not slow down their pace in shipping product. This consequently demonstrates that it's possible to keep the same level of productivity while working remotely.

That is only partially true. Both at Adyen and at Wise, my teams have largely managed to keep shipping features at a similar pace as pre-pandemic: however, what I've personally found is that building pre-agreed upon products is something that goes swimmingly when working remotely - and sometimes even faster thanks to the lower amount of interruptions the engineering team enjoys while working from home. But deciding what to build and how to build it - that is, the gestation phase of a new product - is a lot less effective without continuous collaboration and iteration in the office.

This problem is compounded for junior roles that joined the company during the pandemic: not only they have a harder time getting their projects started (just like everyone else); even worse, because of their limited experience they haven't had the chance yet to mature a discovery and iteration framework yet, which makes it even more challenging to start a new product or project, and accelerate it to cruise speeds.

In this remote environment, product discovery and acceleration are hard even for accomplished professionals. New and junior hires will struggle like the rest of us to get the ball rolling on new ideas; but because of the additional difficulty of bonding with the team remotely, discussing complex ideas using only relatively short structured meetings and planning sessions; and of course because they don't have the necessary experience to run these efforts by themselves, they will struggle to acquire the most important skill for mid-career and senior product managers: that of vision and product development.

Remote working keeps junior people at a junior level for longer, and makes it harder for them to develop product sense.

📡 Network issues

The final and most important issue has to do with how the way collaboration and cooperation works within a large company.

It is completely feasible for anyone to get a good relationship with the team they remotely onboard into - regardless of their level of experience: if the team is good and welcoming and the fresh hire has a modicum of interpersonal skills, remote collaboration in a small team can be as effective as physical presence.

But a junior person entering a new company during this pandemic will usually have very few opportunities to get exposed to the workings of other teams and other colleagues outside of his or her direct vertical. And that's a problem: one of the most important things when building products in sprawling organizations is the ability to coordinate your work with different teams to avoid duplicate work and build cohesive products.

For a person at the beginning of his or her career, it will be exceedingly difficult to get face time and casual collaboration going with other teams. This means a remote fresh grad will only be exposed to a subset of the products within the organization; more importantly, they will not easily reach a position where they become the reference for a given product, and they will have a much harder time understanding how their own team fits inside the organization.

In short, remote working makes it especially hard for junior hires to grow their personal and professional network inside the organization, and to become the reference point for the products they're working on.

Mind the gap

Ultimately, I feel that the discussion about whether remote collaboration is a net positive or a net negative is mostly driven by mid-career and senior people, thought leaders, and experienced employees who can speak with authority. This is true both for internal discussions within companies, as well as the general reflection that's happening in the press and online now that the pandemic is coming to an end.

Personally, I would encourage everyone reading this to think back to their early career days - and imagine how it would have been had they been fully remote from the start. A little bit of empathy would go a long way in agreeing with what I explained in this article; that is, that our remote graduates risk:

• 🙈 not having sufficient opportunities to continuously learn from their experienced peers
• 🚀 failing to develop a product sense, and generally struggle to bring any ideas to the table for new products and projects that might propel their career to the next level
• 📡 failing to develop a professional and personal network of friends and colleagues inside their organization

for as long as their work experience stays fully remote.

Personally, I hope that when this is over and we have an opportunity to return to a physical collaboration model, that even those who love work from home the most will remember to 'pay it forward' to their junior peers, and return to the office - even just once per week - to provide junior hires with the same opportunities we had at the beginning of our career.

There are just north of 6 billion customers that can access your product through a visual interface - and tenths of billions of devices willing to access it programmatically, using a computer interface. This interface is called an API (Application Programming Interface), a catch-all term that encapsulates a wide range of solutions with one specific goal: letting other machines access what your companies does - for a fee.

If this sounds abstract, let's think of the fintech use case of issuing a card. A traditional product is your bank in the early 2000s: you fill in a form, request a credit or debit card, walk to the bank branch, verify your identity, and later get a card delivered at the bank office where you pick it up.

An API-driven version of this is any modern Issuing as a Service platform: someone builds a product that lets anyone fill in forms, request cards, verify identities and dispatch the newly personalized card using a set of specific APIs that another piece of software (for instance, your favourite neobanking app) can call programmatically.

The API product acts as a gateway - or middleman - and charges a fee for that: in fact, most of the fintech services popping up these days are - behind the scenes - powered by a handful of API gateways like Marqeta, SoFI, Adyen, or Stripe. This outlines a key advantage of API products: once built, they can capture multiple markets at once and - by offering a standardized, commoditized set of feature - command a significant share of the cake without having to scale up, reach, and onboard millions of users: instead, API products are usually sold to other businesses, that then use your generic API building blocks to power their own business models (and acquire private customers on their end).

A large part (around 80%) of the work I do these days is API-driven - I spend less and less time designing UI and customer flows; instead I spend most of my days either prototyping services on top of internal or external APIs, and thinking of how to expose our own APIs to other teams in the company or elsewhere.

Thinking about API products can be especially daunting to people new to the whole PM job - as a consumer, we mostly have experience with user-accessible products and services, and building API products usually requires good knowledge of the business line we're in: something that comes with experience.

There are however some general tips I can give to anyone attempting to build an API product - based on best (and worst) practices I've seen in the last few years. Without further ado, here's five things you really need to think about to build top-notch API products:

✨ Great APIs are usable

Usability for an API product is a bit different than your usual consumer interface: APIs target developers and computers, so usability means the API is consistent, behaves predictably, and is well-documented.

This should be an extremely obvious idea; yet there's so many API products that fail at this that I want to elaborate on those three principles:

• The API being consistent means similar constructs are used for all operations: for instance, you shouldn't have half of your API use numerical IDs for customer operations, and customer usernames for the other half. Or you wouldn't want some of your API calls return integers, and other return strings - for the same entity. Your API should be built from first principles that allow you to define a basic 'language' that will be used throughout your product.
• Closely related is the idea that your app should behave predictably. Once you have defined the basic structure that your API should follow, you should aim to build it following the 'principle of least surprise'. For instance, if a given call aims to return a single attribute for a certain customer, you would expect the response to contain the attribute - not a list of attributes, or an ID that can be used to fetch the corresponding attribute. APIs that are consistent and behave predictably can usually get the customer to a first working implementation much faster, and are more pleasant to work with.
• Which leads us to the last point: documentation. Your API should be well documented, and whenever it changes the documentation should be updated to follow. In fact, documentation is an integral part of your API product, and should be written during development (and not as an afterthought) to help enforce the principles of consistency and predictability.

👔 Great APIs follow your customer's business logic, not your product's software logic

This is also an obvious point that plenty of products fail at. You see, developers will build complicated products and once it's time to open them up to a third party will simply slap API routes on top of the existing software functions.

This leads to APIs that replicate your software logic - but are convoluted and difficult to use for businesses trying to integrate with them.

A good API product should be built to accommodate a set of basic use cases for your primary customers, while having solid first principles (consistency and predictability again) that would allow it to scale to future usage patterns. This means it should be able to accommodate your customer's business logic in a way that fits the most common use cases.

It's better to add an additional layer of work between your software and a delightful API, than to map calls to software logic 1:1 and end up with an API that makes no sense to the end customer.

✏️ Great APIs are easy to try

This one is simple enough we can cover it in a single line: your API documentation should have live code, an easy-to-try sandbox mode, or require at most a few clicks to get some test API keys and some boilerplate code or SDK that allows you to get the first API response in less than half an hour.

Now go to your average API product's signup page, and measure how many e-mails, credit card numbers, sign-up modals and general barriers you need to actually get started. Yep: it's another common sense tip that gets overlooked once sales are involved in your API product.

Don't let them do that to your product. Sneaky sales tactics like sign-up walls, delayed API key distribution, and the ever-present 'contact sales' button need to go.

Your API should be easy to try, because that's how you get your product assessed quickly - and considered for the job at hand by a potential future customer.

⛓️ Great APIs follow standards

If there's a standard in whichever sector your product is operating into, you probably don't want to re-invent the wheel.

For instance, in fintech, most transactions are authorized in real time, but the money only moves in batches. Trying to deviate from this model for your API would be an unnecessary layer of abstraction for your final users, and confuse those with previous experience.

It's good to modernize the basic ideas in your sector - and for sure, you can get creative about streamlining your API. But if there's a set of generally agreed upon standards that the ecosystem follows, it's probably best to use them as a constraint during the design phase

😍 Great APIs have fans, just like any great product

A common misconception is that people can have a visceral attachment to consumer products (like an iPhone or a Playstation), but they will never love your API product.

That's not really the case: delightful, well-designed products that make people's work easier, more productive and even teach them new ideas or concept along the way are just as epic as the next piece of consumer electronic.

That's why part of the role is pushing for investment and care towards a full ecosystem around your API - be it a developer ecosystem, developer advocates, good documentation, brilliant tooling and so on. Doing so gives people the feeling that they are dealing with a mature, complete and polished product that 'clicks' well enough to make people love it.

API driven products are less intuitive to build than consumer products - but they can be outstanding and loved by customers too. That's what you should aim for.

The bicycle I owned was a first-generation VanMoof - a hip, fancy city bike with a built-in computer. The computer itself is the bike's brain: it connects to your smartphone via Bluetooth, sends out a distress beacon if the bike has been stolen, and turns the integrated lights and alarm on and off. You can't ride the bike without this last feature.

On a late post-lockdown Friday night, I jumped on the bike after a few drinks and instead of being greeted with the regular electronic boot tunes and the lights flickering to life, I got absolute silence and no unlock. My attempts to start the on-board computer into recovery mode were unsuccessful: whether using the app or the physical buttons themselves, all I got from the bike was a weird 'error' tune. A weekend trip to the store - where they took the frame apart and completely replaced the hardware inside - was needed to have my bike back in a functioning state.

Simplifying failure modes

In my career have been thinking about that 'error' tune a lot. The error tune the bicycle played was completely different from every other sound cue the bike used. In short, the bike is aware that something has gone awry - something that can only be fixed by fully replacing the on-board computer assembly - and it tells you to seek assistance with a classic 'hardware fault' tune.

That means someone designed the boot sequence to check whether something has gone irreparably wrong, and give the 'bleep' tune instead of a regular startup sound.

Which of course means someone signed off on a 'play error tune when firmware is irreparably damaged' feature: someone consciously took a product decision to have the bike recognize that the startup sequence has gone wrong, and instead of trying to fix it, it will simply play an 'error' tune and turn off, stuck in an infinite boot loop.

The knee-jerk reaction as a Product Manager would be to complain about how the product was shipped in unfinished state, and about the abysmal user experience of having to go to a physical store to get Operations to repair your bike.

I'm just not sure that's the case: in fact, I think that whoever shipped this bike with a simple try/catch block during startup and a distinctive 'error' tune is actually a pretty brilliant product person.

Turning product features into operational processes.

When shipping a product it's important to follow the triumvirate of good products: scope well, build well, test well. But, especially when scoping, it's way too easy to overthink every possible edge case. Even more failure cases will pop up when building and testing, and fixing them will quickly turn your strategic product launch into a nasty game of whack-a-mole. As the team morale drops and more features start creeping, you'll start having second thoughts about the product itself

Whoever designed the bike didn't fall for this, and instead managed to ship the product by aggressively solving down a very wide class of problems ('something is wrong in either firmware or hardware') with a single user experience loop:

1. refuse boot sequence
2. play distinctive 'error' tone to indicate user to seek assistance,
3. write a process for operations to solve the issue at the store.

The bike, as a core product, is still operable when this feature is triggered. However, the interface (the lights and sound assembly) clearly signals to the end user that something is wrong. It does so with a very clear, visible and difficult to ignore signal (the unique 'error' bleep). When the faulty state is triggered, the customer gets handed over to the operations team with a 'fix' request, that is performed relatively easily by swapping the ~50 € on-board computer in a few minutes, entirely free of charge.

Imagine the cost of developing all kind of feature flags and reboot sequences for a hardware product, which has no possible way of receiving over-the-air updates. Hundreds of possible edge cases, most of which would never be triggered, would need to be scoped and developed. And of course you'd probably end up missing a few - leading to confusion when the bike inevitably breaks in an unexpected way and goes completely silent.

Within the product's constraint (fast development, no way of updating the firmware, first generation bike only sold in a small geographical region with easy access to brand store for repairs), lifting the 'faulty booting sequence' set of edge cases out of the product scope and into the operations/support scope makes total sense, and is a smart, time-effective and cost-effective solution.

Whoever designed this bike turned a whole class of product features into a straightforward and simple process to be performed by Operations, with minimal impact to the user experience and following the principle of Least Astonishment. The takeaway here is that it's usually better to leave fault-tolerant design to aerospace engineers, and focus on delivering products that are 99% functional and manage to solve the 1% of edge cases with a well-defined operations and customer support flow.

The bike that didn't boot did exactly that - hats off to the PM who shipped it.

The advice to do things that don't scale, however, is meant for early-stage startups; ambitious, scrappy teams that are still looking for what makes their customers tick.

For a product manager joining an established or scaling organization, the goal should be exactly the opposite one: to do products that scale, and product that stack.

So what is a product that scales/stacks? It's a product that:

• 🚀 is viral enough to sustain its own growth (scales)
• 🌱 is financially viable, either directly or through cross-subsidization, in the long run (scales)
• 🤝 has strong technical synergies with the existing offering (stacks)
• 🔁 improves on something that the company is already doing very well (stacks)

In May 2021 there have been some incredible product launches in the fintech space: Airwallex, the global business account, launched own acquiring in Hong Kong; Revolut, the UK-based neobank, launched a browser extension called Shopper, and Curve, the passthrough wallet, launched a partnership with Cardlytics for customer rewards.

All of these are very good products - but do they scale and stack?

Revolut Shopper: stack, no scale

One of the many products Revolut launched in its relentless quest to become a super-app is Revolut Shopper. It is a browser extension that generates single-use, burn-after-using virtual debit cards. It auto-fills your e-commerce forms with this virtual card where possible, and (potentially) gives you an additional discount code to use - reducing friction and increasing safety during checkout.

This is a product that stacks, but doesn't scale.

It stacks, because it brilliantly leverages Revolut's penchant for trying out new things to take control (and therefore stress) away from the user and into their own domain. It has very strong synergies with their existing virtual cards offering, and of course improves on what's already a successful card program by driving additional volume.

But it doesn't scale, because it's neither viral not sustainable. It is not viral, because there is no way for a non-Revolut user to be 'lured' into this product without already having an account: the product can't sustain its own growth, instead becoming an additional service on top of the idiosyncratic set of features Revolut offers. It does not serve as a conversion funnel into the main revenue product (the card program), instead working as another feature most users won't care about.

Its biggest weakness, however, is sustainability. Contrary to popular belief, virtual cards do cost money to issue: for every new virtual card, a fee needs to be paid to the card scheme that issues it; these fees are not negligible, making single-use virtual cards ultimately unviable for purchases (and interchange schedules) that are not business-sized. Revolut either got a deal from the card scheme to have this cost waived for a limited time, or decided to eat the cost in the drive for more customers and more transactions. Neither of these options, obviously, makes for a sustainable product: it only works as long as someone else (either a profitable customer, the scheme or some venture capital) is footing the bill.

This doesn't make Shopper a bad product - it's actually a really cool idea, and might be a successful one: it just doesn't deliver as a scalable product, but only as a stackable one.

Curve + Cardlytics: scale, no stack

Curve is one of my favorite fintech companies: it is a wallet that acts as a bridge between your purchases and your existing bank, giving any boring debit card brilliant superpowers like spending insights and tokenization. Recently, it launched a partnership where a third party called Cardlytics gets (hopefully) anonymized transaction data from Curve's users - to drive market research and insights. Curve's users, in turn, get significant cashbacks (from 5 to 20%) paid out when they shop at certain merchants in the UK with Curve.

This product clearly has significant scale: it has the virality to drive additional customers into Curve, by enticing them with cashbacks that are way higher than even the wildest discounts seen in the industry (even if just at selected merchants): this is a product that is viral enough to drive and sustain growth. And it most likely cost little for Curve to partner with Cardlytics - since the real transaction counterparty is the users' data and spending habits, that Cardlytics will in turn sell to their corporate customers in exchange for more cashbacks and discounts, making it inherently sustainable.

I'm just not sure it stacks as well as it scales.

This is a third party integration, where customers agree to share data with Cardlytics (and its partners): from a technical synergy perspective, nothing (except maybe an exclusivity agreement) is stopping any other fintech to do exactly the same integration with Cardlytics. Unlike the existing rewards on Curve, this is a much smaller moat.

As for the improvement on what the company already does as a core service; well, Curve already has a cashback program, Curve Cash, which has much lower rates (1% to 3%). While it's clear how Cash and Rewards co-exist in the company's offering, it remains to be seen if customers understand the difference between the large Rewards offered by Cardlytics in exchange for user data, and the small Cash(back) Curve already does. The risk of self-cannibalization from the product that Curve actually doesn't own is quite significant.

Airwallex Acquiring: scale + stack

Airwallex, an APAC fintech that offers bank accounts, corporate cards, forex transfers and more to businesses that work across borders and currencies, recently launched an acquiring platform in Hong Kong.

This allows business merchants to issue a simple web link to their suppliers, customers, or partners. By clicking on that link, these parties can pay with a few clicks using (for now) VISA or Mastercard cards anywhere in the world, at domestic rates for Hong Kong, intra-regional rates for Asia and ANZ, and international rates for all other regions.

Out of the three products presented, this is by far the least flashy - and in fact it's the only one that requires a bit of industry knowledge to understand the use case. But when we consider the core business of Airwallex - to let businesses pay and get paid easily and rapidly across borders - it becomes clear that this is a product that both scales, and stacks.

It stacks, because it works hand in hand with Airwallex's existing offering of bank accounts, international bank transfers and card issuance. In fact, it is basically the missing piece that allows customers to never leave Airwallex's platform. By doing so, it improves on something the company is doing well, by closing the loop between spending money (the card), holding money (the bank account), and receiving money (the acquiring platform).

More importantly, it scales as well: customers now need to maintain one less supplier, and in fact can now both pay (using the virtual cards) and get paid (using the virtual acquiring links) inside the Airwallex platform. The potential for virality is huge: when a supplier receives an Airwallex link to pay, they become a prospect that gets exposed to the platform. And of course, it is inherently sustainable, as there is significant money to be made in Acquiring - with or without issuing sinergies - with gross margins often exceeding 1-1.5% of the transaction amount for smaller customers.

This is the iconic product that both stacks on top of the existing product, and scales significantly alongside it.

Stack and Scale

It's always hard to look at products you haven't worked on and try to understand the ideas and decisions (and often random turns) that lead to the features being launched. That said, looking at Revolut Shopper, Curve Rewards and Airwallex Acquiring within the framework of products that stack and products that scale definitely helps in understanding where these products are headed for.

Stacking and scaling are often underrated in an industry that is (at the moment) flush with cash. But I do try to integrate this perspective in my day-to-day work, and always ask myself:

• 🚀 will the product draw customers in?
• 🌱 will it be financially sustainable?
• 🤝 does it fit with what we currently do?
• 🔁 does it improve on our core offering?

Brilliant products don't need to always answer all four questions with a resounding yes. But in the rare cases where your product both scales and stacks, you can almost be guaranteed to have something great in your hands.

After Adyen, I joined Wise - a company that is equally brilliant and equally fast-growing: we're looking to hire 750 people (around 50% of our current workforce) in the first half of this year alone.

Even in normal, non-socially-distanced times, scaling a company's culture and mission is pretty complex and daunting. 'How to scale a company' is everyone's favorite topic, and I don't have much to contribute here.

What I want to focus on, instead, is how to scale teams inside a fast growing organization, starting with the difficult (and unfortunately common) set of team dynamics that can lead to subpar teams; and continuing with some experience on how to attract and retain talent (internally and externally), why people leave, and why they stay.

Excellent teams

Defining what exactly makes a team excellent is tricky: personally, I rank truly excellent product teams along three main pillars:

1. they are ambitious in their promises, and do deliver on most of them: they push the envelope.
2. they are in control of their product vertical and domain: they grow expertise
3. they build internal processes that work for the team, but interface with the rest of the organization with standard processes that work for the org: they speak their own language, but are understood by outsiders too.

However you define it, excellence is objectively easy to assess: a process of either growth or recession will always be in place within your team, with people constantly trying to join good teams - and leaving sinking ships. So, if your team members feel like the team is a consistent dead end, they will leave it (either to another team or another company); external candidates will compare your subpar processes and roadmaps with their own experience and refuse your offers to join. If on the other hand you're constantly overdelivering, external candidates (either from other teams, or externally) will want to join your winning team, and word of mouth and referrals will take care of natural attrition for you.

Based on this, we can sketch a quick 2x2 matrix that you can use to assess what type of team you're into - and whether you're building excellence:

This matrix should be pretty explanatory; but just in case here's a recap of the four outcomes:

First, there's the trampoline team. This is your average team at a successful startup: people are motivated by the potential payoff and by the product vision you have on display, and you can easily find people to join you, either through an internal recruitment drive, or from external pipelines. But a few months in, people get burned out and leave the team, or get demotivated and stop performing, or use their experience as a leverage to a better position elsewhere. This is not an excellent team: in the long run the trampoline dynamic renders the team unsustainable, as the increasingly complex project starts collapsing onto itself because all of your expertise leaves the team after a few months.

The HR clusterf**k is exactly what the name suggest: this is a team that is so rotten that people in it want to leave pronto, and no one wants to join it. This is the team you whisper about in the cafeteria; the team that constantly gets reorganized and that hasn't shipped a feature in a year. It is usually very hard to rescue these teams internally; a functioning HR department (if you're lucky enough to see this type of unicorn in the wild) needs to come in and extinguish the fire; and then you'll have to rebuild.

The internal retirement home team is a team that no one wants to join, but no one wants to leave either. These are usually the oldest teams in the company: they run mission critical services, but lack the glamour and the excitement of pushing the envelope every single day - making it difficult to attract people. However, the work is still fun enough, and the team is well paid after many years of service. This is a good team, just not an excellent one.

Finally, the excellent team is a team that grows fast and steadily - not just because its members are excited about the work and the results, and wouldn't leave if you paid them to, but also because everyone at the company knows you're doing good work - and rumors of your success have spread well beyond the borders of your organization. People actively want to join you, and they don't leave: this is the excellent team you should be aiming for.

Why excellent people join your team

A team is more than the sum of its parts, but getting the right people to join will accelerate your product journey and help your team grow faster and with purpose. Excellent people joining your team - either internally or from other companies - generate a large return, and indeed a large part of a company's growth effort is spent in recruiting, employer branding, profile-raising and ultimately hiring.

It's really up to you to find and convince other brilliant people to join - and that's because, ultimately, the reasons why excellent people join your team are much more driven by your team than by HR or the company itself.

Your company is a sales funnel, but it's up to your team to convert your hiring prospects. So why will they want to join?

🚀 you sell them on the product

The first and foremost reason why people join you, is because they want to help build whatever it is you're building. A large portion of my interviews back at Adyen was spent explaining in detail what the product was and why it was truly revolutionary; I now do the same at Wise, spending up of 25% of my interviewing time actually explaining with full transparency the amazing stuff we're building and why we're excited about it.

You should aim to sell the candidate on your entire product: their reactions and feedback will let you learn valuable lessons about your strategy and execution, and help you gauge whether you're truly onto something. If the product is truly as great as it sounds to you, pitching it to candidates will go smoothly, and people will be impressed and start coming up with brilliant upgrades: to pitch your product to candidates in a fully transparent manner, and discuss with them how to improve it is not just the best case study there is: it's also a valuable experience for both the interviewer and the interviewee, and a good reflection of the way you'll work with the candidate on a day-to-day basis if you end up hiring him/her.

A way I've been able to do this is by involving the team early into the job search , straight from the job description draft, and including pre-sourcing and pre-screening, letting HR only sort CVs and sift out obviously spammy applications. You see, if your team is pushing the envelope, HR can't explain what you're doing to your prospect candidates, instead reverting to platitudes like "disrupting fintech" or "changing the way people pay". The controversial solution to this, is to one-up all of your competitors by moving the full hiring pipeline (except sourcing) into your team.

You might think having to pre-screen a ton of candidates instead of letting your recruiter choose a handful for you is a waste of time for you of your team, but in my experience you're not looking at this the right way. A much bigger waste of time (for you and your candidates) is doing full interview rounds for people that aren't the right fit for your team and for the product, or even worse losing people during the interviews because of weak pre-screenings that didn't manage to sell your candidate on the team. Not to mention the case where none of the people HR selected is a good fit or joins your team, and you end up having to re-open the position after wasting a month or two.

Excellent candidates have other options, but most importantly they want to be truly excited about the mission and product. Would you let HR sell your product to customers? No. So why are you letting them take the front seats in your interviewing pipeline? Sell the candidate on your team and product, and do it yourself.

🤑 you sell them on the benefits

As much as working in an excellent team is fun, people don't work for fun but because they're paid. But if a high salary were enough to convince excellent people to join, then every last one of these guys would be working at Amazon or Google and there'd be no excellency outside of companies that can pay top-of-market. Luckily, that is not the case.

So people won't join because of the monthly salary, but because of the total package - beyond the monetary compensation. This might include for instance the ability to work with people they respect or are known in the industry; to work on technologies or problems that deeply interest them. They might be attracted by the team dynamics you put on display, or by the company's profile online or in the industry at large. If they're smart, they will be attracted by the opportunities to grow and experience new things that might not be there in their current team or at their current employer.

Of course, you should be upfront about what your team can afford in net terms, as well as don't skimp on the monetary perks such as stock options, bonuses, free lunches, tax breaks or the famous ping pong table. You should read up on what the position is offering, and be upfront about it.

But ultimately, monetary benefits are easy to compare: for that reason, it's difficult to compete with the apex predators of the tech market on measurable (monetary) advantages. The key to get excellent people to join, then, is to know your tangible benefits, and sell them on that.

I have never taken the best-paying out of all of my offers when I was looking for a job, and in fact I went for the lowest paying job more than once, because I loved the total benefits. I'm convinced there's more people like me: your aim is to find them and convince them of the value of what you're offering.

🤝 the team sells them on the team

This one's easy: your team should be excited about other people joining your team. For this to happen, the team doesn't need to be winning - but it needs to be happy and well managed, with a culture of excitement, transparency, and fairness.

Once I interviewed for a very cool neobank. During my final interview I asked a question about something the CPO had told me in an earlier discussion. Both of my interviewers stood up - one running to a booth and the other one ducking for the nearest broom closet - so they could rant freely about how short-changed they felt by the CPO, without being eavesdropped on by the guy. Needless to say, if your team is sabotaging your interviews like that, you won't have anyone joining you from the outside. And the same goes for internal recruiting.

Keep your team happy: if your people wouldn't join your team again, why would others?

Why excellent people leave your team

As we've seen from our classic 2x2 matrix, having excellent people join your team is not enough to have an excellent team: you might very well be sitting on the powder keg that's a trampoline team - the chaotic team where people are coming and going every month.

The reality is training people - as excellent as they might be - takes time. So once you've spent the time and effort to have people work in the beautiful machine that is your team, you also want them to stay a long time. In some roles, growth can truly be exponential and there's very few things that are as cool as seeing your teammates evolve in their roles and responsibilities.

Retention is in my opinion even more important than recruitment; and even though some people will leave eventually, you want them to love their job and their product up to their very last day in your team.

When that's not the case, why do people leave?

🙊 you lied about the product

Every product has its struggles, and a big part of an excellent team is fighting together to rectify whatever flaws the product has. If you were transparent about what the team needed, and what the steps are to get the product to where you want it to be, working every day to get to that point is one of the best team-building an career-building experiences you can have.

But if you told someone you needed their expertise in machine learning and then have them sanitize Excel sheets day-in, day-out; if you promised the product would launch in Q1 but it's Q3 and you're still on staging; or if you told them they would be instrumental in driving the product map but you always let others override their decisions, then people will go:

"this is not what I signed up for"

and leave. And you deserve it.

🙈 you compensate your team unfairly

As the previous point already hinted at, people will leave the team if they feel disconnected from it. Now, the worst way to drive a wedge between your team members is to provide differential benefits to some people, whether because of connections, favoritism, because they can negotiate better, or any other reason really.

At Wise we have transparent career maps, everyone doing the same job is paid more or less similarly, and it's clear what the progression, the expectations and the benefits that come with unlocking a higher level of expertise are.

At other companies I worked for, compensation was exceedingly unfair: people doing the same job would get double the salary, there would be no clear career progression (often hidden behind empty slogans like "own your career" or "we have no titles"), some people would get to travel or go to fancy events while others would endlessly slave away. People left in droves.

As a company, you might think transparency and fairness will lead to collective bargaining and ultimately to paying more for the same service. That is not correct: you will, indeed, end up paying slightly more in total for the same headcount; but people will stay for much longer - and the final cost to achieve your product goals will therefore be much lower in the long run.

Ultimately, transparency and fairness are the primary drivers of retention, because few people benchmark against the market, but everyone benchmarks against their nearest peers. In close-knit teams, your peers are your teammates. If someone is getting treated unfairly, they will find out about it, and they will leave you. What's the price of someone excellent leaving - and is it really worth saving 10k a year?

🙉 you don't listen to your team

Your manager's worst nightmare: the high performer, the star, clears his or her throat during office drinks and goes:

"Team, I have an announcement. Today is my last day at..."

Managers will tell you that people leaving out of the blue happens all the time. This is a blatant lie: in high performing teams, no one leaves out of the blue.

You see, looking for a job is a long, tiring and draining experience - no matter how good you are. It forces you to confront your inadequacies, to step out of your comfort zone, and jump into a new role with limited information. And if you're currently working in an excellent team, the likelihood of finding another excellent team elsewhere is not that high.

So people will only take the leap after you've had them cornered for a long time. Maybe they wanted to relocate to be with their loved ones, and you kept stalling. Maybe they wanted to work from home twice a week to be with their daughter, and you refused it. Maybe they felt they weren't paid enough, and you didn't manage to offer a compelling reason why they shouldn't, or a raise if they deserved it. Maybe they felt unsure in their role or of themselves, and you didn't give them enough support. And the list goes on...

By and large, in excellent teams, people will voice their concerns and unhappiness to their teammates and to their managers. If you ignore their concerns for long enough, they'll become louder, and unhappy, and start looking for a new job. By the time you get here, you've eroded all of their goodwill and they are no longer benchmarking internally, but on the market. And eventually, they will leave.

If you conclude they left out of the blue, you don't deserve to lead an excellent team. Learn to listen to your colleagues and your people, and flag concerns early enough, and no one will leave "out of the blue" ever again.

Why you want an excellent team

If you read the entire post, you might be thinking that excellent teams sure are a lot of work. And indeed, you'd be right: a team's natural entropic configuration is that of being not excellent, and it takes a lot of energy to reverse that process and maintain your team's high performance level.

So why would you want to do it?

• Excellent teams lead you to meet truly remarkable people. I'm not just talking about good friends, but about people that will truly change your perspective on how to live your life and what is possible to do with today's resources, freedom and technology.
• Excellent teams turbocharge your careers, which means more options to do what you want, wherever you want to, and (if that interests you), to get comfortably paid for doing it.
• Excellent teams are a pleasure to work with. Even the biggest slackers I've ever met spent at least 20-30 hours pretending to work every week - that's 1/3 of your waking life. Do you really want to spend one out of every 3 breaths you take doing something you don't care about with unremarkable people?
• Excellent teams are the reason why we work. If you work in product or engineering, it's because you like having your brain teased and challenged every day. Don't pretend working in a subpar team makes you happy - if it did, you probably wouldn't be doing this line of work.

My personal advice is to be real to yourself and start charting the course to an excellent team. It's worth it.

A common theme in the fintech space recently is how "the world doesn't need another Neo-bank". Sure, Europe and the U.S. might have indeed reached the saturation point in terms of challengers, the world at large does need more financial apps. More importantly, I think the definition of what's a bank and what's a fintech has clearly expanded in the last few years, creating plenty of opportunities to design something new.

Now, the banking stack is indeed pretty commoditized. In my previous job at Adyen I helped build what's - in my admittedly biased opinion - one of the best neo-banking platforms around, and now at Wise I work on expanding our global multi-currency account.

Both Adyen and Wise have had a significant head-start in building a competitive feature set, and both have significant distribution channels: Adyen can piggyback on a supremely impressive array of business customers, and Wise already had 8M+ users when it started issuing cards.

Yet, that doesn't make it impossible for new challengers to emerge: they would just have to be something else than neo-banks. And sure enough, a growing array of non-financial, non-neobank products have started emerging - with Cleo, Plum, Cake and Emma amongst the most interesting ones in my personal opinion.

For a change, instead of breaking down an existing product (which would be unfair, as my work consists of building the stacks for these services), I decided to put on my product designer hat and think - 'if I were to start a fintech startup without having a banking license and without directly integrating with the financial stack, what would I build?'.

What I came up with - let's call it the Payingforward App - consists of four core pillars: pay, assets, grow and earn.

Pay

One of the biggest changes challenger banking brought along is the proliferation of multiple cards in the average user's wallet. Apps like Curve act as aggregators of other debit cards, being notably limited to VISA and Mastercard cards. Curve's strategy is to get you to proxy spend of all of your third party cards through their own Curve Card. For this they pay to acquire an e-commerce transaction on your third party debit cards (usually capped at 0.2% + scheme fees), pay the issuing scheme fees to the scheme, and get paid the interchange for their own card - most likely subsidizing this whole passthrough operation using VC money or scheme kickbacks now the commercial interchange loophole is gone.

I think there is a way to make Curve's business model work, and it's basically by offering true aggregation to customers (i.e. not just VISA/Mastercard debit cards), and pay for it via a membership fee. That's what Payingforward App would hypothetically do, by aggregating all of your expenses in one place, enticing you to spend through Payingforward's virtual wallet cards using rewards or discounts, and pay for external spending with a subscription fee.

True aggregation would have to come via either proxy spending (already feasible), or via an extension of open banking (foreseeable future) - when this happens, Pay would truly become a commoditized feature.

Assets

There's plenty of different apps allowing you to invest. Insights for banking have long been a staple of fintech apps like Revolut, N26 or Wise. Insights and investments are at the core of Robin Hood or Bux or DeGiro, and there's plenty apps offering pension funds and safe investments as well.

What is still complicated, however, is tracking all of your assets in one place. Apps like Emma work brilliantly in aggregating some of your stuff, but aside from that there's been a notable dearth of interoperability.

That shouldn't be: most of the banking data is now easily accessible via open banking - with alternative data available either via APIs or, more often, screen scraping.

How to monetize this is clear: having primary access to the customer's next investment decision ('help me add more Assets') would allow Payingforward App to act as an investment vehicle platform - much like Raisin does in Europe - effectively becoming an asset gateway.

Grow

A lot of people - and not just millenials - are very unfamiliar with how investing works. Most notably taxes, compounding, asset distribution and retirement plans are the great unknown for a large slice of the population. Apps like Hatch (recently acquired by Octopus) have tried to crack that nut, but the untapped potential of investment planning remains large. If Payingforward App were to go down that route, it would have first pick on offering freeform advice to its customers, de facto steering them in the right direction.

Loans are always controversial - with fintechs like Zopa or Fronted offering to front money with low friction but at high APR. Others, like Cleo, go down the advance payment road, with much lower loan amounts but also lower APRs In the spirit of simplicity, Payingforward App would most likely not have a lending partner or a fintech lending license, instead acting as an aggregator for existing services - letting users choose the optimal trade-off between low interest and high amounts.

Budgeting and jars are some of the most effective way to teach people to manage their finances. Yet most banks (logically) offer jars as a way to separate your money - not to make risk-free interest on it. Apps like Plum pay nominal interests on jars - therefore incentivizing people to store more money in jars.

Finally, subscriptions and bills are some of the ways people tend to lose track of their money - something that will only increase now with the proliferation of buy now, pay later schemes. Energy, insurance and internet switching programs could be a significant driver for Payingforward App to get some kickbacks from brokers in exchange for a fair comparison - a win-win situation.

All this would allow users to consolidate their debts, reduce their expenses and approach investing, ultimately growing their nest through third parties, but tracking it all in a single place.

Earn

The final piece of the puzzle is allowing users to directly benefit from an app that would most likely cost a certain amount per month. Similar to apps like Emma, Cleo or Cake, it should ultimately be clear to the users where they are benefitting from.

Easy cashbacks - based on promotions with participating merchants - and the ability to get paid quickly, either as a business or as a P2P-friendly setup, directly on a third party bank account, would make up the supply side of the Payingforward App, allowing users to earn.

Wrapping up

So, how realistic is all of this? Ultimately this hypothetical Payingforward App would need to support a large number of third party integrations, and figure out for each single feature how to monetize and be profitable while reserving enough money to pay the ecosystem for its services. Distribution would, of course, be a significant challenge in an overly saturated market.

More than anything then, this is an exercise in cataloguing the wide set of features for which there is real user demand and that an hypothetical challenger would be able to offer without going through lengthy, expensive licensing processes. Indeed, a stub of the Payingforward App could be launched by a true handful of people - something that would have been impossible just a few years back.

And sure enough, more and more useful fintech apps that are not traditional challenger banks are entering the space - some of which I've mentioned in this article, and undoubtedly more in the months and years to come, supported by established players like Wise and Adyen.

The world might not need another challenger fintech, but it does need a fintech ecosystem. And as the Payingforward App experiment proves, we're definitely moving towards a very advanced state for that.

What I think is lacking in the online discourse about good product management, however, is a discussion about a few concrete, actual, day-to-day skills I've reliably seen linked with great product managers working at brilliant organizations.

Unlike a "career hack" (which is, by definition, a quick fix), this is stuff you can do on a day to day basis - but doing it won't necessarily make you great at your job. Rather, these are attributes that indicate you have time to focus your work energy to excel at your job, rather than barely manage to fulfill your tasks every day. Like an Olympic gymnast's smile during a difficult routine, doing this shows that you have sufficient bandwidth to perfect your craft - and focus on what matters.

Without further ado, here are some of the things I've seen some of the best PMs I've worked with do at work - and that I personally think are important. None of these is specifically related to product management - they hold for most creative and technical jobs as well. There might be more, but this is all I have for now.

1: 📬 They are available

We often talk about doing deep work, and the ability to take time as a PM to do strategic thinking about what you're building. And that's fair: it's an important part of the role, and you should be able to turn your notifications off to power through your to do list, sketch some design thoughts, or test some of your assumptions.

But availability to your colleagues is just as important as deep work. Especially in large organizations, your product doesn't exist in a vacuum. You will get questions from your colleagues, most of which are actually thoughtful and legitimate. Not answering those questions leads people to build their own assumptions about your product and your competences and take decisions without you and your knowledge. It turns you into that guy - the one who everyone is always waiting for, and chasing. In the long run, this behavior makes your product diverge from the org's vision - no matter how much deep work you do on it.

Reserving some time every day to answer your inbound messages helps you spot those divergences long before they appear. It makes you the guiding star for everything related to your product, and disseminates knowledge about what you're building much more than a quarterly presentation or a weekly all-hands. In the long run, it paradoxically reduces the number of questions you get, as you keep your colleagues' expectations aligned with your vision.

Being available is a positive behavior trait I've seen on all levels - from junior to Chief Product Officer - and it is a key bit of being part of a team.

2: They prep meetings 📝

A lot of people I've worked with - either because of their experience or because of their ego - think that they can just improvise at any meeting. That's unfortunate, since meetings (either face to face or online) are a huge time drain, and should either be useful or not happen at all. It's O.K. having a bad meeting every once in a while, but consistently trying to wing it is disrespectful of both your time and that of everyone attending.

Does this mean you need to circulate notes before every meeting, and do 1 hour of prep work? Please, no. However, you should:

• 🕒 Be on time: meeting delays compound by the number of attendees: 5 minutes late in a 6-people meeting is half an hour of work. Be there when it starts. And finish on time.
• 📅 Describe the meeting in the meeting invite. No one likes to scramble looking for notes or document - not even you. So either link the thing to be discussed in the meeting invite, or provide a short summary in it.
  Not doing so leads to people double-guessing what the meeting is about, questions about the topic, and an awkward first 10 minutes (see previous point). I personally apply the motto 'no agenda, no attend-ah' to my meetings: if there's no description, I will reject the invite.
• ⏭️ (if you're the meeting lead), send a short recap of the action points right after the meeting. As people run off to their next meeting, they will forget half of the things that were discussed. Make it easy for them by sending a short reminder they can go through when they pick up the tasks discussed. Especially useful for recurring items.

A final rule of thumb: you should only schedule back-to-back meetings if you're not the organizer. Stacking your calendar like a little game of Tetris might make you look busy, but it has a terrible effect on your ability to show up prepare. Keep a small 15-minute buffer between meetings to collect your thoughts and do some upkeep, and you'll ensure your meetings are useful, start on time, stay on topic, and are wrapped up with some real progress points in a consistent manner.

3: 👂 They listen more than talk

Everyone likes to give big presentations about his or her own products. But what sets impressive PMs apart is the ability to listen and capture information about what others are working on.

Inside a bustling organization that encourages creative thinking, it's easy to start thinking about new projects and solutions. But smart people will often come to similar solutions through separate paths - and this leads to building the same thing twice.

A common trait of the best PMs I've worked with then - ranging from junior to director level - is the ability to listen and map other colleagues' effort into their own roadmap. That enables them to build impressive products with surgical precision and without wasted effort, not so much by broadcasting their product to the org (although this is important as well); but rather by building a common understanding of other PM's efforts, and shape their own products around those constraints.

4: 🛠️ They grow their toolbox

A lot of product people I interview, especially in more senior positions, and especially at larger organizations, seem to have lost the ability to learn about new tools.

But any organisation that is worth your while is always experimenting with new design tools, new technologies, new productivity tools, and ultimately new ways of getting work done. There's no need to follow the hype, but if you're working on a low-stakes or boring project, why not take the chance to upskill your toolset by getting work done with an unfamiliar tool? Or explain a concept or idea with a prototype rather than with a meeting or design document?

Even more importantly, there might come a time where there is no one available to do the work you urgently need. Learning some basic design skills (Figma, Illustrator and Photoshop at least), some coding skills (Python, SQL and Java), some project management (Jira/Confluence, Asana, Notion) will allow you to solve bottlenecks in a pinch by taking matters in your own hands.

Constantly growing your toolbox makes daily work more enjoyable and ultimately lets you increase your productivity while keeping that sense of wonder you had on your first day on the job - no matter how senior you are.

5: 🧸 They are kind

Picture this: A few years ago, I was in a meeting with a talented person, discussing a very involved piece of work. Part of this work was completed by another team - at record time and with a lot of effort - but it wasn't really up to standards. This person started scrapping large parts of the work, while referring to the team as 'a bunch of f***ing idiots'.

Now, there might be some organizations where this type of behavior is tolerated or even encouraged. It creates a climate of mutual pressuring that leads people to give all they got on their work to avoid being labeled 'a bunch of f***ing idiots' by some senior exec. But it also completely stifles creative thought and leads to low tenure, opportunistic thinking, 'every-man-for-himself' behavior, and a generally stressing environment that is no fun to work in.

In general, the environment you work in can be difficult to change. What you can do, however, is be kind to everyone you work with. Highlight good work, thank them when they deliver, encourage them when they don't. Help rebuild confidence after a failure. Let people know when they have succeeded. Thanking people, celebrations, public shout-outs and the feeling that what others do matters, is noticed, and is loved by you,  go a long way in making people happy to work with you.

A lot of people give this advice with the underlying assumption that it is about karma or about building up some sort of transactional credits. "I was kind to this person, and later he or she helped me reach my goals". That is utter nonsense: if you're the 'opportunistic kind' type of person, people will notice. It might very well be a good career hack for attaining your goals, but it won't do much in making your place of work a happier place.

No, being kind is not something you should do it not because you expect to cash in your Kindness Credits™ further down the line, but because:

• being kind shows you make time to be available and to help others, turning you into the guiding star for a better place of work (see under 1 - 📬 be available)
• being kind makes you happier and gives you positive energy to spend on your own projects
• you'd want others to be kind to you - but that's something that can only be achieved if everyone pays it forward

You won't remember the stuff you worked on 10 years from now - but you'll still remember who you worked with. So make it count.

Back during its original announcement, I wrote an internal post at work discussing a couple points about Libra/Diem which I believed to be sorely missing from the discussion we were having. Almost two years later, I still haven't seen much discussion about three of any currency's cardinal pillars, which are in short:

• Diem's monetary economics (how it fits in the larger monetary system),
• Diem's distribution channels (how will it reach its primary users?),
• Diem as a payment tool (i.e. how do you spend and hold it).

So I decided to pick up the subject once again, and take a look at what - if anything - has changed; and how Libra/Diem fares on those key metrics.

Diem's monetary economics

Most of the current analysis around Diem was focused on the main whitepaper, which mostly covers its mission and functionalities, in a surprisingly high-level way. Companion papers have also been released, with the one concerning the Diem Reserve being by far the most informative.

The goals which this policy paper outlines are superficially in line with those of most monetary authorities around the world. Diem is positioned as a 'Stablecoin' - which is what economists commonly call a pegged, fully backed or fully convertible currency.

In a nutshell, to ensure consumer trust (widespread adoption) and protect it from inflationary or deflationary pressures (value preservation), the Diem currency will is backed by a Diem Reserve. This Reserve is a basket of financial assets, spread geographically and held in their most liquid form.

In layman terms, for each unit of Diem a customer or investor whishes to purchase, the customer needs to hand over some local fiat currency to authorized resellers. These resellers would then transfer this money to the Diem association, which would use it to purchase low-risk assets and currencies. Should the customer want its local currency back in exchange for Diem , for instance to spend it at the local mom and pop shop, the reverse flow would happen. This mirrors the current monetary system, where local banks are the authorized resellers - converting 'credit card money' into local currency - and the central bank fulfills the role of the Diem association.

There's two big economic advantages the paper is trying to peddle here. First of all, unlike existing financial systems, the Diem framework would always hold a 1:1 ratio of Diem to other currencies - something which prompted even reputable news sources to throw the term narrow banking around. Secondly, these currencies and assets would be highly distributed and inherit monetary policy from the underlying central banks.

But both are untrue.

The narrow banking claim, which contrasts the Diem resellers and the Reserve with regional banking systems and their central banks, is superficial and misleading. It is true that the current banking system uses a fractional reserve banking model, in which banks are allowed to use deposit money to finance speculative activities, and are not required to hold reserves covering the total amount of deposits from customers.

However, that does not make Diem's model a narrow banking model. In most regulated markets, banks are not only strongly regulated (for instance under Basel II and III in Europe) and regularly stress tested by external authorities, but are also mandated to reinsure deposit money (what Facebook would call 'low risk') up to a certain amount.

Diem and the Diem Association are under none of these obligations. The 1:1 reserve claim only covers the relationship of Diem to underlying currencies: it offers no guarantee on what Facebook and the Diem Association subsequently do with funds denominated in Diem. Whether it's peer-to-peer lending, local financing schemes, cash-in-advance models, small business loans, derivatives, or even a Diem PE Fund, the reality is: you wouldn't know.

Once the money is denominated in Diem it escapes regulation and oversight, and enters a new dimension where the bank is the money. That is not narrow banking - in fact, it's the wildest form of grey market capitalism: and what Facebook calls a "commitment to strong consumer protection" is a call to regulation that only covers the exit nodes - the "endpoints", which would traditionally be seen as currency exchanges.

Facebook wants these exchanges to be regulated - but not its currency; and that hasn't changed with the rebranding. For all other intent and purposes, the Diem ecosystem is an unregulated distributed monetary authority - the furthest you could be from a narrow bank.

As for the inheritance of monetary policy, you could buy this argument for large nations with strong regulatory power, large technical departments and huge currency reserves. But for smaller players - think about the central bank of a developing country - this whole project feels like a play from Facebook to have additional leverage: a concern that, to my surprise, I have failed to see anywhere in the current analysis of Libra/Diem.

Diem's original focus on banking the unbanked clearly betrays a focus on developing economies - which is where the need for liquid, safe, and stable money is the biggest. But that's a double-edged sword: imagine Diem becoming a successful product, in, say, Myanmar. People would get paid for their services in the local currency, the Kyat. Due to its superior stability and ease of cross-border transfer, the Diem would be a better solution to hold savings. But as citizens exchange Kyats to get Diem, the Reserve would slowly fill up with Myanmar's currency.

The mandate of the Diem Association, in that case, would be to re-balance the Reserve's currency basket. But for developing countries such as Myanmar, the amount of foreign reserves held is usually low (for Myanmar, a few billion of dollars). Re-balancing the basket from the Reserve would mean flooding the market with Kyat for a value similar or superior to what the Burmese central bank can exchange would cause runaway inflation and cripple the government in its ability to function.

Giving this type of power to companies such as the Diem Founding Members is something that deeply worries me. 'Banking the unbanked' is a development project that should not be taken lightly: financial ecosystems are difficult to work with, even more so in fragile, developing markets; and Diem's monetary paper fails to address any of the concerns that would arise in the minds of any reasonable economist.

For the reasons stated above, I would rate the claims about the 1:1 backing of Diem-to-currencies making the Diem association a fully regulated player that is subject to external monetary authorities as misleading. At the time of announcement I would have expected monetary and financial authorities around the world to do the same - and that has largely been the case.

Diem as development vehicle

One of the major selling points Facebook is presenting to the world for Diem is that it will 'bank the unbanked'.

The story goes like this: around 30% of the world has no access to financial services, but they all have mobile phones and internet. So why would you force these poor souls to carry wads of cash along some dusty road in the middle of nowhere to get their groceries, when they could just hit that Like button on their iPhone and have them delivered at their doorstep like we do in the US?

It's a compelling story - especially because it's one we, the rich world, desperately want to believe. But it fails to take into account the reason why the 'Unbanked' are cut out of the global financial system.

You see, people in developing economies have money - usually more than you would expect - and they would probably like to buy goods and services online. The major issue they have is not in fact their lack of access to the global financial system. It is lack of access to the local interfaces. People in developing countries have a very limited array of options to move their Paper money into the Internet dimension. To use a metaphor, the problem is not that they can't travel by plane: it's there's no landing strip. Building yet another plane - or another wallet, in this case - will not help at all.

Diem has been compared in some circles to M-Pesa, the phone-based wallet active in some Subsaharan countries. So how does M-pesa solve this local access problems? Lo and behold, here's the local bank I used on the daily back when I was living in Africa:

Which one is the bank you ask? Well, all of them: the shop with the 'Wakala' sign (literally, 'agency') is the one carrying official mandates from the financial network to act as an ATM. But almost every other brightly colored door houses at least one financial endpoint - commonly called agents. In fact, even the guy riding the motorcycle on the right can act, in some cases, as an ATM on wheels.

Financial endpoints like the one in the picture have unclear availability of financial services, open and close at seemingly random hours, and have incredibly steep conversion fees (to the tune of 5-10% of transaction value) when bridging the gap between the digital and the tangible world. Which is the problem at hand: all the financial optimization, fancy Blockchain and beautiful UX will not help one bit if the interface between Internet Money and Real Money is this shoddy.

Facebook and the Diem Association have been unable to provide a clear answer on how they plan to actually reach financially underserved regions. I have no doubts they can be more successful in the digital domain than any other digital wallet in the space - which is where the fight with their venture investors is played. But the other battle - the one that really matters, the one to bank the unbanked - plays out on a different battlefield.

Which is why at the time I was unable to buy the idea of Diem as a legitimate bridge between the Unbanked and the digital world. Two years on, the Diem Association has not managed to crack the puzzle of how to roll out a gigantic capillary network of local agents in the developing world - a strategy which in any case was incompatible with their goal of low fees, money liquidity and strong regulation.

Paying with Diem

A final point worth considering is the one about Diem's main purpose: as a payment method.

In my day-to-day job I get to see a lot of the machinery being built to allow people to pay everywhere, no matter what. A Taiwanese tourist going through a London Metro turnstile with a single swipe of its Visa card might not make headlines - but it is an incredible technical achievement when you consider the amount of machinery that is present just to process a few pennies.

Diem was clearly inspired by two incredible innovations in the Payment space: the rise of Aggregator Apps, and that of P2P payments.

Aggregator apps (also called super-apps) are something that the average Western consumer would not be familiar with. They are incredibly popular in many markets where the whole e-commerce ecosystem was sorely lacking: Aggregator Apps changed that.

The whole idea behind an AA is that the app itself serves as a sort of 'embedded app-store', which allows you to do many things at once, without having to install any additional software. Customers get ease of use, a single interface style, and a bunch of interconnected applications with shared accounts and a single wallet.

Indeed, most of these apps (AliPay, WeChat, Meituan Dianping, Go-Jek, Grab, Rappi) started as or include at least rudimentary wallet functionality. But beware of comparing them to Paypal: they are a completely different beast. On one of these Aggregator Apps you could find a date, find the best restaurant, book a table for two, have a friend rate your looks, order a cab and plan the whole night without pressing the 'home' button once.

Aggregator Apps are something that is really hard to understand from our cultural point of view, where information, goods and service are readily available. For emerging economies, they are a revolution.

I'm sure Facebook was looking very closely at different success models in other markets. By partnering with some of their potential competitors in the Diem association, they were definitely looking to be the Super App of the West.

P2P payments have been around forever (Western Union anyone?), but thanks to the rise of borderless shopping, travel, and personal finance they have now reached a whole new dimension. There's basically two ways of making money transfer work financially: you either create economies of scale and networks large enough that the money basically never needs to leave your system (Venmo, Swish, CashApp, Paypal.me), or you work very closely with existing entities to bring down fees by negotiating partnerships (Visa Direct, Mastercard Moneysend).

The problem with either approaches is obviously that the more parties are involved in the whole transfer chain, the higher the fees to make the process financially viable.

At the time, I fully expected Facebook to aim for the first type of P2P wallet: one that is fully integrated in the Facebook ecosystem, but more importantly - one in which your money never exited the Diem system. And I would have expected the model to expand to include companies as the second Peer, effectively cutting out the middleman in C2B payments.

That is largely what happened - which of course created an interesting tension in the Diem Founding Charter: half of the companies represented were net recipients of revenue generated by global payments, and the other half were the ones that need to cough up the money. At the time it felt like the entities that bought a seat at the table have wildly different motives to do so - and, as I wrote, "it remains to be seen how that will impact the project going forward".

Sure enough, Visa, Mastercard, Paypal, Stripe and the other potential peers ended up leaving the Diem association after under a year. But that hasn't stopped Facebook's ambition to become the Western World's Aggregator App: they launched dating services, communities, scaled up their marketplace offering, and most likely still plan to offer access to money and services from a single hub, therefore owning their customers across all channels.

Diem is still very much part of this play.

Final thoughts

I think the interest towards Libra (now Diem) is still justified, but for all the wrong reasons. Two years on, most of the commentary still focuses on its Cryptocurrency aspect - and yet I've managed to cover most of what there is to say about Diem from both a payments and an economics perspective without mentioning 'Crypto' once.

On the other hand, the payments and monetary perspectives are the ones that will determine Diem's fate in the market. Under the current regulatory environment, I would not expect Facebook to be able to become the West's first Aggregator App; let alone the first supra-national currency.

But even if they fail, there will be others. Libra's original anthem pleads for a currency that is "safe, accessible, no matter who you are, or where you're from". That is an admirable goal, and one the industry should most definitely stand behind. A world where money works for everyone is exactly what we need - I'm just not sure that money will be Diem.

Edit 25.04.2021 - An important counterpoint to this analysis from a friend who's heavily involved in the tech: the processing fees are exceptionally high this quarter because of the technology still being relatively new. Scaling the Ethereum network with layer 2 solutions such as Optimistic and Zero Knowledge rollups would reduce transaction fees up to 1000x, making the economics work.

After a few years of working in fintech, there are three topics that still manage to confuse me: corporate taxes, HR (the department), and the economics of cryptocurrencies markets. I think it's time to address the least complex of the three, focusing specifically on a market I'm very familiar with - and that has been in the news a lot recently: the crypto NFT art market.

Deconstructing art markets

The best approach to talk about a crypto-something market, is to start by disassembling the existing product, understand how adding crypto into the mix aims to improve it - and see whether the 'new and improved' version is effectively better than the vanilla one.

So let's look at the art market: a longstanding institution that can be traced back all the way back to ancient Greece in the West, and the Qin dynasty in the East. Items sold on an art market command a price based on their rarity, and of course on an underlying appreciation of their subjective beauty and meaning - evaluated by the buyer, or by a knowledgeable third party. The bid-ask spread is generally large, as this is not a liquid market, goods are not interchangeable, and sales are either executed by private deals or by non-efficient English public-bid auctions.

It is by and large a speculative investment market, with returns that are lower than other investment vehicles (estimated around 2 to 3%), but relatively difficult to tax and regulate. Sure enough, the Art market is one of the shadiest around, with  untraceable, harmless, difficult to sanction goods moving across borders and geographies with relative ease.

What about the creators? Looking at at the latest UBS/Art Basel report on the Art Market's sale price distribution, the 'starving artist' cliché seems to hold true: out of an estimated 30-40 million private artworks sales every year, only about 5% falls north of the 250,000 USD strike price milestone, with around 80% of the goods sold for less than 50,000 USD. In the auction space, we can see a similar story: of the 17 billion USD of auctioned goods in 2020, less than 3% was sold for more than 250,000 USD - and more than half of all auction sales are executed below 5,000 USD. Most artists make little or no money at all.

Add some crypto

Crypto art markets have been around for a while (OpenSea, which I use for my analysis, was founded all the way back in 2014), but it's only recently - driven by a global pandemic, record cash supply, and general ennui - that these markets have become mainstream, with new large platforms like Rarible or Foundation starting operations in 2020.

These platforms are digital auction houses, allowing (anonymous) sellers to list, buy, and sell Non Fungible Tokens (NFTs), which are at their core digital certificates of authenticity and ownership for an underlying artwork. The artwork itself is digital - usually viewable on the platform itself, on third party storage, or on peer to peer data platforms like the Interplanetary File Sytem (IPFS). By itself, the artwork is worthless: what gets sold is its digital representation, baked into the NFT contract. It's not the artwork, but the NFT itself, that is transferred from buyer to seller.

Crypto art markets claim to improve on the existing setup in three ways:

1. they are more democratic: by moving sales into the digital realm, they allow anyone to buy the art they like straight from the creators, therefore allowing underrepresented categories of buyers (think anyone who might not feel confident walking around at Art Basel or visiting an art gallery) to purchase art.
2. they offer an higher degree of trust: because the NFT is traded on a blockchain, ownership is determined by node consensus and origination is as easy as following the trade all the way to the initial wallet. While it is possible to duplicate or copy the underlying artwork, unlike traditional art it is not possible to modify it (since its representation is traded with the ownership contract), nor to forge the ownership certificate (the NFT)
3. they drive liquidity back to the artist. Unlike traditional art markets, where valuations are driven by gatekeepers (critics and dealers), crypto art markets let artworks sell for their actual value by demand and offer, therefore liberating artists from the complex structures of social economics, and allowing any worthy artwork to be sold for a high price, with the artist pocketing most of it.

These are compelling arguments - but do they hold true?

Art for the little man

The first and arguably most interesting claim is that crypto art markets allow anyone to buy and sell art online, in an easy and approachable way. As I write this, NonFungible - which aggregates multi-platform sales data - lists around 125,000 monthly artwork sales, with a total sales value of around 180 million USD, and around 36,000 unique wallets transacting.

Ignoring a few caveats, we can draw a general comparison with the global art market, which moves around 5 billion USD a month, of which around 1 billion sold online during the Covid pandemic. Getting an estimate of unique buyers is harder, but the UBS/Art Basel survey goes out to 9000 different dealers and art galleries, each reporting an average of 54 unique buyers. If we draw a parallel between these 486,000 buyers with the 36,000 unique wallets, we can see how the accessibility of the traditional art market is actually quite similar to that of the vanilla online art market - just on a different order of magnitude.

The assumption of collectors skewing younger in the crypto art asset class might also be uncalled for: in the general art collector space, more than half of all buyers are actually millennials. The image of older demographics going to art fairs, and rich kids buying crypto assets on Rarible is not accurate at all: despite the difference in total scale, the divide between the crypto crowd and the modern art collector looks to be relatively small; way less than the one between extreme trading communities like Wallstreetbets and the traditional retail private investors.

Most importantly, this difference is most likely driven by the online aspect of sales - and not by the underlying technology. The internet is the true catalyst for differentiation here, and the introduction of the crypto token component is simply a different way for similar investors to purchase the same class of assets. Art for the little man? Maybe, but most likely, art for the little investor.

Digital deeds

The second assumption is that of security: art forgeries date back to the very origins of the art market, and centuries of thievery and counterfeits have given rise to an entire cottage industry of trusted action houses, authenticators, deeds and certificates.

On one hand, credit where credit is due: NFTs on a digital decentralized ledger are indeed more trustworthy than any deed in the physical realm. For as long as there are nodes (computers) running instances of the blockchain on which the art tokens are registered, it is possible to trace their origin and subsequent sales with relative ease.

One important caveat here is that the asset and its underlying NFT token are entirely decoupled. Much like a certificate of authenticity and the artwork it authenticates, digital artworks and digital tokens are in fact two separate entities. The deed itself is virtually impossible to falsify, but the artwork it represents can in fact be duplicated like any digital asset. The price of any artwork in a collectors' world is driven by authenticity, but also by scarcity: if anyone could conjure an atomic copy of a Picasso or a Klimt out of thin air, as you can for digital assets, would their price be impacted?

The answer is yes and no. Digital artworks have indeed commanded a lower price, on average, than their physicals counterparts. But art forgeries have existed forever, so indeed the price of any piece of art is mostly driven by an entity certifying its authenticity, regardless of whether it exists in the real world or not. For traditional art, that's either an authenticator or the auction house. For digital artworks on the blockchain, that's the NFT itself. And for as long as the blockchain on which they are registered and the place where the artwork is stored exist, the piece has value.

This last point - the preservation of value in time - is an important one to make. NFTs are decentralized, meaning they only keep existing as long as enough people have the incentive to run instances of the ledger they are minted on. And digital assets are in constant flux as well, either because of technological change (who, today, can open artwork made with Amigas or Commodore 64? Or play a floppy disk?) or by the extinction of the platform on which they are stored.

Art survives global disasters, wars, famines, fires and floods not by being fully traceable, but by being resilient - with resiliency driven by a very flexible network of authenticators, collectors, art lovers, and dealers. It is largely unclear to me how well the digital equivalent of these - in the form of NFTs and future evolutions thereof - will display the same level of resilience and adaptation: the introduction of crypto assets into the mix increases trust in the short term, but (in my opinion, at least) introduces brittleness in the long run.

Feeding the starving artist

So what about the third point: giving the art back to the artist? We've already seen how the art market isn't filled with the multi-million-dollar sales that are reported in the newspaper: on the contrary, almost half of all private sales, and more than 2/3 of all auctions end up at a sale price below 5,000 USD.

On top of that, many art pieces don't reach the sale floor at all: the UBS/Art Basel report points out how, especially during the pandemic, many lots have been withdrawn from sale altogether - because of curators fearing low value or no bids at all. Once again, the marketplace - and not the artist - is the gatekeeper here.

So how does a crypto marketplace fares instead? Unlike traditional auctions, NFTs are trackable by design, and accessible via API. So I scraped the 50,000 most recent sales on OpenSea and converted the sale price to a fiat currency (in this case, USD).

This is what we get:

The bottom 50% of all artworks here sold for under 1,867 USD - a significantly lower tail than the traditional art market. And in fact, in our representative sample, only the top 5% of the market gets close to the 5,000 USD mark: a number that pales compared to the right-hand tail price distribution of the top 5% of traditional art sales.

More importantly, as we discussed earlier, many lots never reach the sales floor in a traditional auction house. Conversely, in the NFT crypto market every single lot is listed as either direct sale or auction.

Yet many of those lots are not being sold at all. In a representative stream of over 10,000 events on OpenSea in April 2021, only 5% of all events were artworks actually being sold (either in a direct sale, or as a completed auction), with an additional 6% of events being bid placed on ongoing auctions.

A whopping 89% of all event traffic on OpenSea was due to new artworks being listed. Since the sale rate includes secondary sales, this concretely means that 9 out of 10 artworks on sale on the largest NFT market in the world never get sold at all.

Which is a problem, because - unlike in the real world - listing artworks can have a significant cost.

Gas Gas Gas

Because of the decentralized nature of the NFT ledger, parties running consensus nodes must be incentivized to participate in processing new transactions being added to said ledger. Most NFTs (around 95% in our OpenSea sample) are minted and exchanged on the Ethereum network, where the incentive is a monetary reward in Ethereum tokens.

Minting (i.e. creating) the artwork has a processing cost, which is paid by the artist. Buying the artwork (and transferring ownership of the NFT) also has a processing cost, borne by the buyer.

Platforms like OpenSea offer two types of minting. With standard minting, the NFT is immediately decentralized: it gets created and placed onto the ledger for a fee, and a second fee is levied when the NFT is sold and transferred. With light or lazy minting, on the other hand, the artwork is only listed on the (centralized) marketplace, and not on the blockchain. Only when the artwork is sold (or a winning bid is reached) is the processing price paid for both minting at selling at once. This difference is important, because only standard minting preserves the fully decentralized artwork authentication assumption NFT markets aim to solve for. Unfortunately, it also has a much higher upfront processing cost, which is paid by the artist.

This processing cost is paid in what is basically a secondary auction that rewards decentralized parties (miners or enthusiasts) with gas for processing instances of the ledger. The more gas offered, the faster the contract will be added to the ledger. And the more complex the contract is to process, the more gas will be needed. Unlike traditional payment or authentication systems, that have a fixed and a variable fee, the gas cost fluctuates (just like the value of the currency itself) based on demand and offer.

Much like the underlying currency, the gas price is highly volatile when denominated in its native currency (because of demand and offer), but also additionally volatile when converted in dollars (because of fiat/crypto forex volatility). Since there is a time difference between when the artwork is minted (for a certain ETH gas fee) and when it's sold (netting a certain amount of ETH), fluctuation in the ETH/USD exchange rate leave the artist holding significant risk. Finally, additional complexity is driven by the fact that different contracts may require different amount of gas - an amount that is quite hard to estimate.

On average, for the transactions I scraped, minting an artwork cost around 100 USD in gas fees, with the lowest total gas prices hovering around 22 USD (mint and sale), and the highest processing fee well north of 200 USD.

If, as we've seen, the average NFT sells for around 1000 USD, and the average transaction costs 100 USD to process - but only 5% of actual listed artwork end up being sold, then the community as a whole is losing money.

In fact if the entire OpenSea sample were to be run as a fully decentralized crypto art market product, then for every dollar of revenue, the artist community on aggregate would be paying up to a whopping 5 dollars in gas fees. And this is before platform fees, conversion, forex, registration and commissions are taken into account.

Cui Bono?

'Cui Bono' is a saying minted by Cicero - one of history's first recorded art collectors. 'Who stands to benefit?' is indeed the question that we should ask ourselves when trying to make sense of complex systems.

The traditional art market does work as a product, employing more than 3 million people on top of countless artists worldwide; the crypto market does not. Like many crypto-related "innovations", its benefits in terms of democratizing regulated systems and empowering individual creators are dubious at best. And the claims of security and resilience, while not entirely incorrect, lead to a system that is both opaque and complex. Sure, the innovative NFT-based authentication and increased democratization of an insular market might look like a step forward; but unlike the traditional art market, the underlying economics here look utterly unable to sustain this system - not even during the initial gold rush.

The most heartbreaking part of this scheme is that NFTs are being positioned by the crypto community and the mainstream press as a way to empower artists to claim back the reward for their endless, beautiful creativity. In reality, artists are losing money - to the tune of up to 5 dollars lost on every single dollar of revenue before fees if their artwork is minted direcly on-chain. They are left holding the bag here for large institutional investors who do benefit from Ethereum's meteoric rise, for the miners being rewarded running the proof of stake algorithms, and for the marketplaces like OpenSea or Rarible who pocket between 3 and 15% of an artist's sales.

Platforms like Patreon, Ko-Fi, Bandcamp,GoFundMe and, yes, even OnlyFans, have shown that there could be a way for connected marketplaces to empower artists, connect them with supporters, and provide stable and significant sources of revenue that allow anyone with talent and drive to focus on their creativity rather than on paying rent.

Crypto art marketplaces, on the other hand, are volatile constructs that are inherently inefficient, opaque and complex, easy to manipulate, and whose ultimate cost is borne by the more vulnerable amongst the artists they claim to help.

More than a payment scheme, they are a pyramid scheme. Avoid them if you can.