Building modular software

Product strategy

Design leadership

Published Dec 2022

·

🥹 23 min read

During my time at airfocus, I got to participate in shaping the strategy of airfocus as a company, not just the product. This case study is about the said strategy. If you’re interested in product design and the implementation side, you can jump into a more tactical Product Design study.

In a nutshell:

  • Team: Malte Scholz (CEO, CPO), Christian Hoff (CTO), Valentin Firak (CMO), Julian Tieman (Engineering) Eike Reikhart (PM), Yours truly (Design)

  • Duration: 6 months

  • Outputs: New value proposition, product architecture, product strategy.

  • Outcomes: $5M Series A raised, ~ 4x ARR (obviously not a direct result).

During my time at airfocus, I had the privilege to participate in shaping the strategy of airfocus as a company, not just the product. Discussing said strategy is a central part of this case study. If you’re interested in a more tactical product design and the implementation side, you can jump into this case study

1. The challenge

To get a good grasp of what we did and why we did it, we have to understand the two facets of the situation: Where airfocus was as a product in relation to where the company needed to go, as well as where product management was as an industry and what needed to happen

I joined airfocus in Feb 2020. Back then, it was the world’s best prioritization platform for product managers. This was evident by every competitor copying our solutions to varying success. airfocus had something going for it. But a changing landscape of product management meant that airfocus had to grow to fulfil its mission of building a home for products, and the people who build them.

1.1 Research

I didn’t conduct any direct user research during my time at airfocus. But I did have a reliable stream of information coming from:

  • Hundreds (literally) of conversations that founders had with customers: For over a year, every new user received a concierge onboarding and well as near-instant support from the CEO and CMO. During my first few months, multiple of these calls happened daily.

  • Sales conversation: our CMO was part of the product strategy team. Because he was leading our sales efforts, we had a great understanding of what people were looking for.

  • CS: airfocus boasts perhaps the best CS of any SaaS that I’ve ever seen. While this has a high cost, it’s also an endless stream of data. We knew what’s keeping our users, what they struggle with, and what’s driving them away.

In Addition, these were direct channels were we could validate every idea with potential users and get early feedback before we got invested in the solution.

1.2 User profile

Expected outcomes

  • Expect to Replace some of their tools, not add to them

  • Expect to be offered the latest stack of product management tools, not just roadmapping

  • Are allergic to large, clunky PM monoliths like Jira or Aha! and expect an experience in line with what they’re being offered in simple tools like Trello and Canny.

Values:

  • Centralization: Tool fatigue is rampant in product management. There’s an endless stream of companies trying to sell cookie cutters to product managers. A tool that doesn’t fit doesn’t stick, even if it offers outsized value. It tends to fade off the PM process.

  • Lightweightness: The product space is full of large, powerful solutions. Yet, those tend to be complex and ghastly platforms that nobody enjoys. Jira, with its flaws, is not one of the worst.

  • Configurability: Unlike engineers or designer, product managers operate in a various ways. Excellent product management software allows PMs enough latitude to accommodate the intricacies of each project. (More on this later)

1.3 Challenges

We built a gradual understanding of the challenges that face airfocus. These were not nice to haves to increase numbers by double digits. These were existential threats to anybody selling software to PMs:

  • Not everyone was interested in any set of tools: 50%+ of users didn’t use our prioritization tool. Not everyone user the roadmaps either. Each saw the other feature as a distraction or an unnecessary at best.

  • Tool fatigue was a prime driver of churn: Conversations with exiting users and especially churned ones revealed that product manager can’t stick to airfocus because it’s a new tool on top of their already large stack. Even though they clearly enjoyed using it, it couldn’t stick because it didn’t fit into their other workflows.

  • Product management was changing: When airfocus launched, nobody had heard of things like insights management. By the time I joined, it was a major reason that we were losing entreprise deals. Other fringe tools like public voting portals and OKR management were becoming a standard expectation.

  • Collaboration is a must: Product management is a team activity. PMs, by definition, must collaborate with other members of the product team, product marketers, leadership, users, and other PMs. A Great solution plugs into the existing systems used by everyone and allows them to seamlessly participate in PM as well

1.4 Insights and the new product strategy

The key learning in airfocus is this: Scalability is the foundation to a successful product management application. Therefor, we are basing the entire strategy on airfocus’s ability to grow.

But it’s only natural that products scale. What’s so special about our case? Not just product, Socrates argued that this is a natural tendency of not just people, but of even the most perfect of settings, namely his republic. It seems to be a rule of nature that things tend to aquire larger scale with time. This seems to be a product of entropy.

airfocus has a subtle but powerful distinction. Almost all applications naturally grow larger to increase their scope and the value they offer to users. But growth is not a condition for them to live. Scale is often convenient but for airfocus, it’s vital. It’s the only way it can make sense. It’s growing and will continue to grow because that’s the only way it can survive.

This is also not an economy of scale question. This is what happens in an environment where replacing competitor is built into the incentive mechanism of the market.

I think this is similar to the plight of layer 1 blockchain solutions. You can’t just have a blockchain for NFTs alone because then you would need to carry your tokens from that network and tokens of the other network where you do your DeFi and another Token for where you do your Gaming and so on. What that does is devalue each token, so you’re back to having to rely on barter of Fiat currency which defeats the whole purpose. Every user is incentivised to reduce the number of networks that they’re on. The solution that sensible blockchains have understood for years now is that there’s no way out of scale and interoperability.

The value proposition of airfocus is its ability to cover as much of the PM landscape as possible. Modularity is how we could do that.

Building more features creates bloat, hampers speed (no matter how good your CTO is at engineering), and affects discoverability. Your Eisenhower matrix is not going to help you solve this one. This is Hick’s Law which creates ****the scale paradox.

As we’ve mentioned, what’s original about the airfocus situation is that scalability was not an inevitability like it is for most other apps. It is the pillar on which we rest our entire value proposition.

Once we understood that scalability was the name of the game, modularity is really a no-brainer. airfocus bet the house on this problem because it made perfect sense, and it had no downside; It had what you’d call an asymmetric payoff, in principle at least.

2.1 Making the case for modularity

Modularity is the idea of splitting a system into clearly defined chunks. It’s an exercise in Modeling and abstraction.

When we mention modularity, this brings to mind modular soviet buildings or maybe the ill-fated modular LG phone. But a better analogy is modern Mobile device operating systems like android.

We didn’t discover modularity. Software engineers have discovered this a long time ago, and industrial engineers before them. I think that modularity is going to become a condition in today’s complex products. In a sense, it kind of already does exist in you look at ERPs (think Zoho).

We can already see glimpses of it in most major products in and the form of power-ups, plugins, extensions, templates. These used to be only present in heavy applications like browsers or prosumer grade tools like photoshop. Now Every app seems to have extensions.

But it’s only not plugin-like apps. A lot of other aspects of the experience can be made modular.

Building more features creates bloat, hampers speed (no matter how good your CTO is at engineering), and affects discoverability. Your Eisenhower matrix is not going to help you solve this one. This is Hick’s Law which creates the scale paradox.

As we’ve mentioned, what’s original about the airfocus situation is that scalability was not an inevitability like it is for most other apps. It is the pillar on which we rest our entire value proposition.

Once we understood that scalability was the name of the game, modularity is really a no-brainer. airfocus bet the house on this problem because it made perfect sense, and it had no downside; It had what you’d call an asymmetric payoff, in principle at least.

2.1 Making the case for modularity

Modularity is the idea of splitting a system into clearly defined chunks. It’s an exercise in Modeling and abstraction.

When we mention modularity, this brings to mind modular soviet buildings or maybe the ill-fated modular LG phone. But a better analogy is modern Mobile device operating systems like android.

We didn’t discover modularity. Software engineers have discovered this a long time ago, and industrial engineers before them. I think that modularity is going to become a condition in today’s complex products. In a sense, it kind of already does exist in you look at ERPs (think Zoho).

We can already see glimpses of it in most major products in and the form of power-ups, plugins, extensions, templates. These used to be only present in heavy applications like browsers or prosumer grade tools like photoshop. Now Every app seems to have extensions.

But it’s only not plugin-like apps. A lot of other aspects of the experience can be made modular.

You collect bundles of functionality under clear conceptual models. The advantage of these models is that that they act as categories which reduce the cognitive load on the user, which is one reason why it’s great for scalability.

To get a sense of how that looks like in practice, take a look at the old airfocus interface. I would be remiss to mention that even though it has ample areas of improvements, it did work very well and it would have continued to work if it didn’t need to grow by 3 or 4x in 2 years.

Notice the following:

  • ❌ You can see that there is no visual distinction between Board and Integrations. Board is not considered a view. It’s a part of the experience that doesn’t belong to any clearly defined category.

  • ❌ Notice tat the page is to to “Items”. That would suggest that “chart” isn’t full of items, so is board and timeline. That’s not true. they are all lists of items. But the existing conceptual model didn’t dictate that these be seen as views because “Items”, admittedly a poor name, was closer to an app than a view. you went there only to prioritize. We had to extract the prioritization from that view

  • ❌ Notice how There’s no notion of Fields. You have lanes, swimlanes and groups which are parameters of views that apply to the items. The new model would see them become fields which the views can reference to function.

In the new model, We introduced the idea of the workspace settings, which would house all the modules. It’s not that we’ve introduced new things, we’ve just categorized them in scalable categories. This is what makes modularity a driver of scale.

2.2 Validation

In today’s age, it’s expected of product teams to know that they should validate ideas before taking it into code. This is how successful products are supposedly ran

This approach is good as a guideline for a beginner design and product manager to start to get into product design. It’s also very effective in highly certain environments where the scope of the designer is mostly fixed. You can do this to fix a certain metric or reinforce a certain behavior, but if you study any successful company that made a new paradigm in their field, it really can’t work like that.

  • The main problem that we all chose to ignore is Henry Ford’s quote: “If had asked people what they wanted, they would have said faster horses”. This is an unsolvable problem.

  • User’s rejecting an idea is usually grounds for dismissing it. But if you present users with something radically different, their judgement doesn’t account for much. I know this first hand as I have resisted Figma for many years. Native software was my mantra and I couldn’t see past that.

  • In highly integrated systems (systems where outputs are used as inputs, think a temperature regulator), the system doesn’t make sense in part. You can’t test part of a car. You can test the entire car and it would be great. And then you put larger wheels on it and it ruins the entire experience.

  • When the scope of the research is “everything”, a problem can always be addressed further up the river or with a hack. It’s difficult to know where to test.

So here’s where this model fails:

  • In a new product, the triggers are endless. It’s not an exercise in prioritization as much as one in vision and strategy.

  • Because of the highly integrated state of our system, everything we tested always made sense. And yet when you put it together, it doesn’t necessarily fit. So this means that the prototypes would have to be so comprehensive that you’ll be pretty much building it

  • The main issue with showing people prototypes is that their judgement is that of a first time user. Figma doesn’t make sense the first time, neither does WordPress. And yet you use them enough, things change.

There’s an imperfect way out of this, which is what we did: building with users. We had a large pool of users, super users, team members, advisors, product management leaders, and we exchanged with them the entire way, for 6 months, 12 month, 18 months... It never stops because we’re not building a set of sharp statements. Instead, we’re building expertise, and a sound sense of the problem and the user.

This is an organic process that evades diagraming. It’s how real, complex, and fun design projects are ran.

2.3 In Summary:

  • The challenge of Product management software is scale. Tools need to replace other tools to survive. To replace other tools you have to grow horizontally. Horizontal growth challenges UX.

  • Modularity solves the scale paradox because it enforces cogent information hierarchy

  • Continuous discovery and validation are the only way that complex, highly integrated products can be built

3. Critique

I’m very happy with the work that we’ve done. After rolling out the updated version of airfocus, we got a lot of positive feedback about the new UI. Yet was was more important, and was really the goal of the project, is that we got the ability to scale the project into the future without having to worry about bloat and complexity. at last, airfocus can focus on delivering all the solutions that the market wanted, without hampering the existing experiences.

3.1 Build to sell

Videographers have a great rule: Shoot to edit. This means that as you’re shooting your scenes, it’s great to have in mind how you’re going to edit them later. What matters is not just the quality of the shot, but it’s how it’s going to fit with all the other shots. This mindset makes for smoother transitions and a clearer storylines.

In product, I want to promote a similar dynamic. We need to build features that will sell, rather than build features that are “great”. Great, doesn’t necessarily sell. There’s a bare minimum for what the platform needs to have, everything else should be prioritized based on what will help with acquisition.

I don’t want to hear anything about what people are asking for. Tell me what’s selling. Heck, if we can get over the ethics of it for half a second, I recon that one ought to test what will sell with ads about feature before building them. What sells gets built. What doesn’t gets taken behind the barn and shot.

One thing that I think we got wrong with airfocus is that we kept trying to keep up with what the market was asking for. We listened to the users, as we’re often told by successful people who are indeed as clueless as we are. I, as the “User’s advocate” am guilty of promoting this fallacious proposition. True, that’s my genuine role as a UX designer, which I uphold ferociously. But I was also in the position to give strategic input and for that, building strategy on user requests in a fool’s errand. The same could be said for anything else other than sales.

(edit: feb2023: I just read Grove Gardner’s “Blue ocean strategy”. 2 decades ago, he had figured out that feature-parity is usually not a good idea. It’s a race where all participants lose)

We were building the features that help us stay ahead or at least on par with the market. We were building to be able to say “yeah, we have that too, and it’s better here”. I think we did a terrific job at that. It would have been perfect if airfocus acquisition was mostly sales based. But for a company that relies in part on advertising and inbound marketing, it’s not the best approach.

I don’t know how big is the reliance on sales in airfocus, nor would I share it if I knew, but I know we advertise because I have designed our ads. Having done that, I know that our story isn’t sexy. airfocus is great once you use it for a couple of times, kinda like Notion and Figma and all other robust, well thought-out platforms. It also makes great sense if I get you on the phone to explain it. But on an ad, it doesn’t look different. It’s like an Armani suit. Looks pretty much the same as an H&M suit in a Banner Ad.

airfocus is better. There’s no doubt about that. It’s also different, but it’s only different in ways that don’t translate well into ads.

I think that once we had the basics, we should have focused on building sexy things that will sell, as opposed to things that will provide the full value. Sounds like would be said on the boardroom of some evil corporation that pollutes rivers and exploits Vietnamese children, right? I admit that.

But maybe there’s a reason those corporations are big. They understand the game. Bring people in, get market share, raise a whack-ton of money, and then worry about delivering. The difference between us and said evil corporations could be that we would still care about delivering. Our ethics means jack squat if we don’t capture enough market share. Our day-to-day messaging should not be to sell the truth. It should be to not sell lies. There’s a large difference.

An example of a feature that I can’t get over is the “auto-roadmap” app. I’m not certain this would be a life changer from a usefulness perspective. I think so, but I’m not sure because I haven’t fully thought it through and tested it with real people. What I do know is that it does have the profile of things that tend to sell. It’s clear, different, and has immediate upside potential. Truly valuable or not, It’s great for advertising because:

  1. It can blow up our acquisition numbers because we would have a great story to tell. This is great for us for obvious reasons, and it’s also great for customers who would certainly fall in love with airfocus once they try it. The purpose of this app/feature is to get you in. That’s it. Let the rest of the platform convince you to stay in. As the Dogecoin community says: “Came for the money, stayed for the community”. The airfocus motto could be “Come for the auto-roadmap, stayed for the modularity”

  2. It can get people to talk about our work because it’s radically different, innovative, and exciting. Sensible is not great for business. Sensational usually does better. Religion figured this out a long time ago. Time to take a page from one of their books.

  3. Increase the perceived value thus help with funding. Here’s the truth: ain’t no investor excited about another Kanban platform. Until they’re told some ridiculous story about a thing that’s half impossible, they’re not likely to write a fat check. You’re gonna get a healthy check for a healthy story. Not for me. I’m more interested in those obese checks with the type 4 diabetes, like the ones Pitch.com got for building exactly nothing at all.

This part is purely speculative. I don’t know any of this to be true. All I know I that it makes some sense. Defense is not always the solution. At least play offense once in a while for Odin’s sake.

3.2 Missing the value proposition

Maybe this first one isn’t necessarily a product related critique, but I wanted to mention it here because I think it did have product implications. I think we made the terrible error of considering modularity as a selling proposition.

You can’t sell modularity because modularity is the way you built the product, not why people are buying it. Modularity is not a selling proposition therefore it shouldn’t figure on any communication material, let alone as a prime sales pitch.

Henry Ford did not figure out how to build a car. Actually, the model T was inferior to many cars that were made at the time. What Ford invented was a way to make a whack ton of cheap reliable cars. When he went to the market to sell his thing, he didn’t sell a car that was built on Ford’s revolutionary assembly line process. He sold a car that was cheap and reliable. How he made it cheap and reliable is only relevant to Ford and his associates.

Some people confuse this as features vs benefits… none-sense. It’s mechanics vs value-proposition.

Likewise, it’s not clear to me that the airfocus prospect gives a damn if we have the most modular platform under the sun. The airfocus prospect doesn’t know what modularity means. We can teach them, and that was the plan. We would invest a lot of money in creating this market. But we could just give them what they wanted because we had it and it works.

They want a lightweight, easy to use platform that replaces most of the their product management stack. Yes, I know. Ford’s customers had nothing to do with his assembly line while airfocus users are going to be immersed in modularity. But the analogy stands. I wish I’m wrong on this one, but I don’t think so.

If I had to sell airfocus to someone today, I would tell them that that the reasons they should use airfocus is because it combines the strongest feature set on the market, with the best user experience. Both of those statements are undeniably true. Try it. I think the team uglified it since I left 😄, but it’s still delightful.

I did take on a strategy and marketing role in airfocus, but I still consider this blunder to be a mistake that I made while wearing my product design hat. Product design is the best asset that growth has when it comes to learning about the value of the product. I think we got caught up the the technical superiority of our solution and overfed it to the growth team. They too should have known better, but still. I take the blame on that one.

I hesitated before sharing the following because it’s a clear case of where I was dead wrong. I remember stating, with the utmost conviction, time and time again, that “Good user experience is cannot be a USP. It’s a condition”. I used to make witty analogies like: “When Proctor and Gamble sells me shampoo, they don’t tell me that it smells good because they know that every shampoo also smells good these days. Smelling good is a requirement in a shampoo, therefore, by definition, it cannot be a USP”.

While this is certainly correct, I made the two following mistakes

  • Not making the difference between good and great. Good is something you keep using. Great is something you tell people about. Good is a VW Polo. Great is a Golf GTI. It could have been a valid goal of ours to build the the product management platform with the greatest user experience. For that to work, we would certainly have had to make it leagues better than what it was when I joined, but that’s precisely the sort of thing you challenge your team with. That’s a goal worth having. That’s a fair goal. I’m convinced that Modularity has already gotten us there. Just don’t advertise modularity; advertise the effect of modularity: Great UX, that don’t get worse with scale.

  • Not realizing that in the product management space, a nascent space, good UX is far from the norm and there’s a lot of market share to be captured by riding this USP for a while. To follow my own analogy, if most shampoo didn’t smell great, you can bet your house that P&G would sell you on the best smelling shampoo, the shampoo with the fragrance that lasts the longest, the largest collection of fragrances, the fragrances that were developed in France by a guy called Jean-Philippe LeSomething.

One of the reasons I made this mistake is because I’m a power user, a hacker, a tinkerer, as are most of the readers. I find most products fine because I can Frankenstein a solution with any half-decent product. The words of my mentor Mohammed Khalloufi still ring true: “Ayadi, people are not you”. This was never in the sense that I’m smarter because I’m clearly not. In part, it’s in the sense that people don’t have the same interest in figuring out how to make shit work. They certainly don’t derive pleasure from doing so. If their satellite receiver doesn’t work, they call the guy. If their computer is slow, they call the guy. If their Excel sheet takes 14 minutes to load, they go get a coffee. If their product management software sucks, they switch to one that sucks less. They certainly do not “Figure it out”.

I think I missed the value proposition. I hope I’m still not missing it now.

contact@ayadighaith.com

I’m Ghaith Ayadi [ɣaajθ ʕajadiː], Designer of sensible software, writer of Hokum 🍉

Working remotely from Lisbon · AI free 🥳

contact@ayadighaith.com

I’m Ghaith Ayadi [ɣaajθ ʕajadiː]. Designer of sensible software, writer of Hokum

Working remotely from Lisbon · AI free 🥳

contact@ayadighaith.com

I’m Ghaith Ayadi [ɣaajθ ʕajadiː]. Designer of sensible software, writer of Hokum

Working remotely from Lisbon · AI free 🥳