John the Factotum

Strategic Hierarchy

There are infinite ways to develop a technical product. There are a lot of well-documented processes that seem to have some proven efficacy. But there is a layer up from process that deserves way more thought if you're playing the long game. I'm no product management expert or entrepreneurial genius, but I've been around the block a few times. If I had sufficient capital to start my own company and do it right, this is how I would prioritize my decisions and resources.

1. Objectives #

If you want to align a team and enable distributed decision-making, documenting specific objectives is essential. If I have an understanding of the company objectives, I can apply that framework to any situation and know if my decision is serving the objective or not - to know if I'm taking a step closer to the goal or a step in the wrong direction. OKR is a great framework to apply.

2. Brand #

The word "brand" means different things to different people. To the uninitiated, it means colors, fonts, and logos. Those things definitely are part of the brand, but really those are the end product of brand definition. The "brand" that I'm addressing here relates to how the world perceives your company and product. These are the words that describe the feelings people have when using your product and interacting with people from your company. There are a lot of brands that can be discerned by just mentioning a few descriptive words:

A well-defined brand helps answer the question, "Would our company do xyz and do it in this way?" So, between objectives and brand definition, I can make a decision understanding if it moves us toward an objective and it's doing it in a way that reinforces the perception we want customers to have.

3. Team #

Now it's time to establish the team. This doesn't necessarily mean that I would put off hiring anybody until after objectives and brand have been established. By this point I would have definitely engaged some trusted relationships to help with those most strategic decisions. What I'm trying to address here is that the team that's going to do the work and establish culture needs to be created. These are do-ers and jacks-of-all-trades. They're people that love challenges and think big. They speak up when something isn't up to snuff. They are pragmatic in their decisions and execution.

4. Process #

Next I would focus on how we work. I've said it in a previous post, but aligning the team around an explicit process is huge. Make no assumptions based on the team's prior experience. Establish a process based on well-documented, proven methodologies. DO NOT THINK YOUR ORGANIZATION IS SOMEHOW SPECIAL AND MAKE UP YOUR OWN PROCESS. GREAT ARTISTS STEAL. Iterate as necessary, but don't change for the sake of change. Oftentimes we abandon perfectly good process only because we lack the discipline to see it through to the point of reaping the benefits. Be patient, but think critically.

5. User Experience #

User experience professionals gather data in order to formulate holistic user experience hypotheses that are validated with testing. Notice what I did not include in the definition:

All of those things that I didn't include are downstream of user experience execution. When discipline is exercised in the methodical application of user research, your customers will beg you to take their money. You will also save a TON of money in software development since features have already been validated.

6. Technical Foundation #

There are two weeks at the beginning of any tech project that will save you years if spent wisely. After you've spent a few days proving the concept of your product's functionality, put away the POC and don't touch it until you have established the patterns that will allow you to iterate and deploy as quickly and confidently as possible. Before you even think about deploying your POC, these are the boxes to check:

  1. The most basic form of the app you're going to deploy. (ex: the stock create-react-app with no modifications)
  2. Some form of centralized source control. (I prefer Gitlab just because it's free to host a private repository.)
  3. Automated tests set up in some kind of CI orchestrator. (Gitlab CI, Github Actions, Jenkins...whatever)
  4. Test coverage reporting and static code analysis.
  5. Infrastructure as code (IAC) with remote state management (Terraform/OpenTofu is great [for now]. Gitlab CI has remote state management.)
  6. Execution of IAC in your CI.
  7. App build + deploy from CI on every merge into your main branch. I prefer to deploy both staging and production at the same time every time. (See step #8 for how.)
  8. Feature flag implementation. Preferably you use a third party for feature flag management, but I recognize that this can be spendy.
  9. Pull request workflow with gates based on test coverage and static code analysis.

Now that all off that is established, which takes shockingly little time, you can port your POC into your repo(s) and start running FAST. All the impatience you could feel building will be released in no time and will be nothing compared to how you'd feel in a year otherwise.

7. Instrumentation #

What gets measured gets managed. At this point it's time to invest in 1) making sure that you know about technical problems with your app before you hear it from your customers, and 2) that you know what functionality is making your customers happy or frustrated. Both of these goals require instrumentation. I spend time instrumenting the application to track performance and alert on anomalies. Then I'll want to be able to track user behavior and feature performance. Instrumenting to measure user behavior is 1000x easier to do up front than when you have a mature code base. Instrumentation should be a part of the rhythm of work rather than an afterthought.

This is the point in the process where I would ask myself, "What if we're marginally successful?" In other words, what if we have decent traffic, and we need to staff up and scale our app? What would we want to know? How can we make our lives easier at that point? How do we make sure our margins don't tank? Using standard tools in standard ways is a great answer. Google Analytics can be your friend. Beware of Google Tag Manager. Centralized log management will be essential, but watch your log levels. You might not be able to afford New Relic or Data Dog, but make sure it's easy to add when you get there.

8. Features #

Now...finally...we can start coding features. This is where I might invest in product management. Or maybe as a founder you fancy yourself as the best product manager ever (not likely). Regardless, now it's time to lean into the process, prioritizing features, and building toward the minimum viable product to be launched. If you've checked all the boxes above, this will go FAST. It will also be ridiculously predictable as you measure the team and lean into the discipline of the process.

9. Iteration #

Launching the MVP can be framed as having launched a data-gathering device. Leaving anything as MVP is the same as telling your customer, "You're only worth my minimum effort." Why should they stick around? Remember: We want them to throw their money at us - to create such a perceived imbalance of equity in our exchange that the customer almost thinks they're getting away with something. We instrumented our MVP for a reason. It's time to run experiments and make hypotheses on feature iterations and additions.

10. Sales + Marketing #

If I'm doing things right up to this point, word-of-mouth is creating more than enough business. I've always thought that if I have to trick you into buying my product, I don't have a product worth buying. To me, sales and marketing are a last resort. Maybe it's because I don't like selling (but I also acknowledge that everyone is in sales at some level). I also acknowledge that the world is a big place. Hopefully I have a large market to address. To do that, I'll want to make sure that potential customers can find my product and make a purchase. The good news is that it's easy to measure the effectiveness of sales and marketing and the cycles are relatively quick in tech. Be careful, though. You can definitely grow your company into oblivion.

11. Optimization #

After all of that, I have a crank I can turn. Now I have something that I can optimize for the smaller gains that will yield larger results with scale. To be clear: It's often easy to spot opportunities for optimization before this point in the priorities. Resist the urge to prematurely optimize. It's hard. I know. But I also know that all of the above will create giant levers to amplify any optimizations I might make.

Doing it Wrong is Normal #

My experience is that almost no company follows the priorities listed above. Here's a quick rundown of typical priorities and what pain it causes...

  1. Features
  2. Sales
  3. Iteration
  4. Optimization
  5. Team
  6. Process
  7. Brand
  8. User Experience
  9. Instrumentation
  10. Technical Foundation (sort-of)

The Pain

Things move fast at first. The norm is low-discipline - fast and loose. It seems awesome. "We're crushing it! So many features for our users!" But of course, these are only assumptions that the right features are getting to customers and that the customers are having a delightful experience. Customers are less than impressed. So sales and marketing get added to the equation to drive top line revenue and expand market share. It works, but now the bottom line is suffering. All the while, the small-but-mighty team is iterating and fighting fires - continuing to add functionality at break-neck speed and creating some of the most spectacular tech debt ever conceived.

Top line starts improving, and it seems like maybe there's a real business that needs to be operated. It's time to start optimizing sales and sprinkling in customer service to tend to struggling customer experience. The application is starting to show signs of instability, so it's time to apply some rigor to incident management. (Why would we ever stop to fix the root cause?) The engineering team can only support so many heroic efforts, so it's time to hire more developers and throw some hardware at the problem.

Now the team is growing and it's time to add some structure. Because there is very little discipline as a part of the engineering culture, applying the discipline of a "real" process seems silly. The "process" gets made up in order to accommodate the team's natural way of working.

Since market share has increased, the risk of any product iteration becomes amplified. Because features have always been more important than tests, the team has no idea if the changes they're making are going to wreak havoc when deployed...YOLO! The team engages in manual testing of deployments. Now that deployments are scary, there is a decree that they should happen only during off-peak hours and no more often than once a week. But now that the team has grown and the deployments are infrequent, the deployments are huge! The rollback rate is high and it's super hard to figure out which change introduced errors.

Things...slow...way...down.

What happened to all the "velocity"? Fists pound on desks. "We need to move faster!" Obviously the "process" is the problem. It's too heavy.

Meanwhile, it's time to play catch-up in other areas. Sales are slumping. The problem must be the brand. Time for a re-brand. The font is the problem.

Somewhere along the way, somebody persuasive comes along with some experience and starts whispering about UX and CI. And the team starts the very quit-able, long walk up Kilimanjaro, hoping there's enough food and gumption to make the summit, not knowing how far away it is or how many times they will slip all the way back to the base.

I've lived it many times. I've been the root cause a time or two. Please leverage my experience. Save yourself!