Finding your ASANA to win in the Age of Software

In my previous post on “building bespoke AI products to win in the Age of Software”, I discussed how innovative organizations invest significantly in building their own proprietary AI products. You can also look for inspiration on what kinds of AI products you could build for your organization in another post I wrote “how to build a digital twin in 6 months for 1M USD”. In this post, I will discuss a framework that can help you ride the tides of rapid change both within your organization and its environment.

1. Effective leaders in the Age of Software find calm and comfort despite the chaos of innovation

To measure the success of and give direction to your AI product strategy, I propose a framework which I named ASANA. The word “asana” comes from the practice of yoga. In yoga, students often choose to challenge themselves in difficult positions (e.g., Eka Pada Rajakapotasana, also known as “pigeon pose”). Reaching asana signifies finding calm and comfort despite the challenges. Advanced practitioners have learned to overcome the pain and stress to a point where they can even find peace and meditate for a few moments. I believe becoming an effective leader in the Age of Software is an exercise in finding that comfort zone in the face of frequent challenging situations.

2. Reaching your ASANA to overcome challenges associated with building AI products

You have reached ASANA when you and your organization have found the following strengths:

• Availability: you have access to people with the right skills and ready to deliver, regardless of whether they are employees, contractors, or external talent providers.
• Speed: your product builders are made of small squads that focus on crafting AI products that will exponentially benefit the user experience and are not held back by technical debt.
• Agility: your teams respond to change and are focussed on delivering great user experience.
• Necessity: the case for change is made, and your leadership recognizes its necessity.
• Affordability: the full lifecycle is costed out, including the risk of failure of your fledgling venture, the maintenance of a successful product, and any licensing costs.

I now take you through each dimension of the framework in more detail.

2.1 Availability

No matter how talented the people in your organization are, there will always be more qualified and ambitious people outside your team. The question is: how to reach out to them?

In addition to your regular human resources hiring processes, headhunters, and online marketplaces, you need to be ready to go the non-traditional route to avail talent. In fact, the best developers may not have a LinkedIn profile, and may not pass through your screening interviews.

Here’s my not-so-secret secret to find great product builders: go to your absolute best engineer or designer and ask them who the best person they know within their skillset is in the world, and in their network. Ask them for introductions .

At all times, you need to have at your fingertip a short list of people you can bring onboard quickly and the mechanism to utilize them even if they don’t want a permanent home in your organization. Central to availability is the dynamic process required outside of standard HR to flow talent in and out of the organization at a moment’s notice.

Can you assemble a team in a day? Can you engage a niche vendor in under a week? If you are having trouble attracting or retaining those people, ask your best designers/engineers why, and fix it.

2.2 Speed

Assuming you have solved your availability problem and have the right people with the right skills, the next biggest impediments to going fast will be your teams’ size, software development processes, and team health:

1. Too many team members and too many stakeholders/users,
2. Mismanaged software development processes (e.g., not writing enough tests, overlooking cybersecurity, accumulating technical debt, etc.),
3. Lack of emphasis on team health.

2.2.1 Smaller is faster

First, the bigger the team, the more overhead is required. Let me demonstrate. Assuming that each team member needs to align once a week with every other team member for a minimum of 1 hour, then we have the following:

1. Team of ONE has 0 minutes of alignment meetings, but has limited bandwidth.
2. Team of TWO has 2 hours of alignment meetings (twice 1 hour), or 2.5% of their time.
3. Team of THREE has 6 hours of alignment meetings, or 5% of their time.
4. Team of FOUR has 12 hours of alignment meetings, or 7.5% of their time.
5. Team of FIVE has 20 hours of alignment meetings, or 10% of their time.
6. Team of SIX has 30 hours of alignment meetings, or 12.5% of their time.

How about a team of 15? A whooping 210 hours wasted every week, which is 35% of each and everyone’s time! Assuming 8 hours of work a day, that’s almost 2 days every week dedicated to meetings. A team of 41 people would literally spend 100% of their week staying in alignment but getting nothing done. The result is that people on larger teams don’t communicate enough and become uncoordinated. Sounds familiar? If your product team is going slow, the solution is simple: remove people.

Another sure way to go slow is to try to please too many stakeholders/end users at the same time. A product team is better off making one user extremely happy than ten users moderately happy. Be a little bit ruthless and politely ignore stakeholders that are not helping you push the product forward. Start small, stay focused and grow from the core.

2.2.2 Slow is smooth, smooth is fast

What percentage of time is your team dedicating every week to writing tests, discussing security mechanisms, or reducing technical debt? If the answer is close to 0, then you have a ticking bomb on your hands. When it explodes, your ability to deliver features fast will come to a screeching halt with a lot of wasted momentum.

By ensuring that important software development details are done correctly (e.g., adopting something like Gitlab flow), you will go slow to go fast. At the other end of the spectrum, if you don’t have any technical debt, you are probably not pushing enough features out. However, when it comes to cybersecurity, the bar for being careful should be incomprehensibly high, to the point that people find it mildly annoying but still comply. Not surprisingly, one of my least read blog post is about cybersecurity, yet I think it’s a post that will remain relevant for a long time. I learned a lot when researching it (e.g., I contrasted cybersecurity with the US Navy’s quality assurance program for its submarines) and I hope you will enjoy it.

2.2.3 It’s not a sprint, it’s a marathon

The choice of the word “sprint” in Scrum is unfortunate. In fact, Agile (discussed in the next section) promotes sustainable development:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

By the time signs of depression start to show up, it’s already too late. Health is an important topic for me. I touch on it when I give feedback to people and I practice Brazilian Jiu Jitsu multiple times per week. Quoting from those posts:

An Athlete lives healthy - they will care about getting sufficient sleep, will eat nutritious food in moderate quantity, will exercise moderately but frequently, and will take the time to relax, decompress and meditate.

In business, there are many consequences that can arise from working too hard. Three very visible external effects could include: 1) Lackluster performance on the family and friends front: divorce, missing out on raising the kids, not keeping up with important friends. 2) Poor mental health, resulting in anxiety and depression: 40 million adults in the US are affected every year according to ADAA. 3) Risk to self-actualization: when so much of one’s personality becomes tied with a professional persona (e.g., being a partner at a venture capital firm), any professional setback can engender a toxic spiral of self-doubt.

By pacing myself in my career I’ve been able to participate wholefully in raising my kids with my wonderful wife, I find myself able to overcome any signs of depression, and I take the time to self-actualize through learning things I find interesting (for example, last year I took a Coursera course on Aristotle, Epicureanism, and Stoicism).

By emphasizing that the team gets plenty of sleep, finds time for wellbeing (e.g., exercise, meditation, games), and invests in learning new things, the team will not only go faster in the long run, but will also achieve things which are otherwise unattainable.

2.3 Agility

The Agile framework is trivial to explain and can be summarized in twelve principles, but it is hard to master. If you are looking for a definitive set of processes (e.g., sprint reviews, backlog grooming, retrospectives) and tools (e.g., a Kanban board in Gitlab), you will likely be disappointed with the results. You will end up with an “Agile Theatre”, where actors do lip service using the right terms, but underneath it they have yet to profoundly accept the discomfort of ambiguity that comes with agile.

Agile is not a process, it’s a framework and a mindset.

You are not going to get it right the first time. In fact, you are never going to get it perfect - ever. But, iteratively, you are going to question your assumptions every week and fix a small fraction of those until it’s good enough. You will frequently release software and observe users in action. If you gain new insights, you need to be ready to adjust quickly.

Unfortunately, that may mean killing off a product if you identify you are not solving the right problem. Other times, it will be taking a sharp turn to pivot in a new direction. And finally, the solution may be to split up a team into two, assigning different sets of features to each.

A good way to ensure you can scale down teams quickly (and mitigate negative employee morale) is to incorporate into your talent strategy some flex resources. Here’s three examples:

• free floating employees (e.g., out-of-role rotations, interns, etc.),
• independent contractors, and
• outsourced product-building companies.

Adopting the Agile framework and mindset can be incredibly hard for organizations where waterfall planning is so ingrained. It is the reason many companies opt to hire Agile coaches. A poor sign that your organization has adopted the Agile framework and mindset is that you have a checklist running around to ensure that every Agile ceremonies are completed (i.e., the process is followed). A better sign is that your Agile coaches have nothing to do (because team members have adopted the Agile mindset).

Do your teams have short, clean, and prioritized backlogs? Your end users need to feel that they are being listened to, and your product builders need to know that the features they are releasing are having a positive impact.

2.4 Necessity

Necessity is something we can well define in evolutionary space. Necessity is a trait that satisfies the minimum requirement for survival under parameters that are selective. Sometimes, specimens can survive without meeting the minimum requirement because their general state is overall favorable. But, over time, selective pressure will tend to hone in and follow that necessity.

While each case has its own peculiar signature, this is how innovation propagates. We live in the Age of Software, but transformation and adoption is progressive. There are different kinds of checks that keep change from happening too fast. Visionary entrepreneurs have the ability to identify necessity and find ways to accelerate that change.

If you have availability, speed, and agility, then your case for pursuing your necessity is growing. Necessity is the easiest to achieve in a startup but the hardest in a publicly traded company.

But identifying properly which product will turn out to be “necessary” in real time isn’t going to work out more than 10% of the time. In fact, if your batting average is higher than 10%, you are probably not going at bat often enough and are leaving a lot of opportunities unaddressed. You have to have confidence that the 10% that does succeed will be worth 100X its investment. If you don’t think that way, you are taking a huge risk of letting your competitors out-innovate you.

Consider the case of Y-Combinator, which has funded over 2,000 companies since 2005. As of 2014, they had invested over $12M in those companies, and today that number might be north of $20M, but not much more. As of 2020, the top 5% (102 companies) have a cumulative valuation of $155B, including companies such as Stripe, Airbnb, Cruise, DoorDash, Instacart, Dropbox, gusto, Reddit, Docker, Twitch, GitLab, and Flexport.

There is always room for innovation.

Are your leaders so engaged with building your products that they too get involved in quality assurance? If your leadership sees the necessity, they will make room at the top, they will promote people with the proper skills, and they will create career paths where people can continue to be hands-on.

2.5 Affordability

Because you are going to try a lot and are ready to fail, you will learn to run cheap experiments. If you keep your team small, you should be able to build a proof of concept in less than two months while maintaining a burn rate under 100K USD per month. If your proof of concept is successful, be ready to launch within six months for less than half a million. If you have been successful with one product and are now at the stage of fragmenting the team into 2-3 semi-independent product feature teams, scale accordingly but continue to have a long term view.

Every AI product that you build will continue to require maintenance over its full lifetime. Having a sustainable strategy over the long run is essential. The best people to continue to maintain and improve a product are the people who built it in the first place. It is essential to take that into consideration.

If you are considering building on a platform that requires you to pay licenses, go read first my blog post on Building Bespoke AI Products to Win in the Age of Software. The short answer is, the opportunity cost in terms of control over the service means you probably shouldn’t. That doesn’t mean the answer is always to build everything from scratch. Good candidates for licensing are companies that offer a consumption-based API as a service. For example, Stripe for payment processing, Twilio for SMS, and Google Maps API for maps. These companies offer services that are highly reliable and available, are priced competitively, and have documentation that is publicly accessible.

3. How can you tell if you are on the right track to reach your ASANA?

Because your environment and the state of your organization are evolving in a constant feedback loop, you can never quite reach finality in chasing your ASANA. Yogi masters will tell you that it’s about the journey, not the destination. In mathematical terms, you can only reach your ASANA asymptotically. As Mike Tyson said in his great wisdom “everybody has a plan until they get punched in the mouth.” There will always be a lot of blood, sweat and tears during the journey.

Regardless, there are a few indicators that you are on the right track. If you can muster a team within the day, have super-users that recommend your product, have leaders that are actively involved in enabling others, removing barriers, and are not afraid to take calculated risks, then you are well on your way to produce a few unicorns, with enough magic dust to reward everyone involved.

---

Acknowledgement: thank you David Castonguay, Leah Capitan, Denis Ouellet and Suzanne Fournier for your contributions to this post.