Observations of an Early Operator pt. 2

Continuing where my last article left off (if you haven't seen it, you can find it here )--I wanted to share a few more lessons that I've picked up during my early stage operating journey over the last decade.

Focus

When it comes to building a company, new shiny objects appear on a regular basis. Of course, it always makes sense to evaluate if a new technology or logistics solution can enhance your product in any way. Not doing so would be borderline irresponsible. For instance, I'm sure there are a large number of start-ups currently attempting to figure out how to weave AI into their product offering. For some, it may make complete sense. For others, it is most likely a stretch, that could end up as a very costly mistake.

Stay the course. Spending too much time trying to fit a square peg into a round hole will have your limited resources running dry and team members unnecessarily stressed. Now, if whatever you're currently doing isn't working, continue to explore and iterate. However, keep in mind that you do need to give certain approaches time to prove their viability. Being impatient can also hurt you.

If you have found product-market fit and have some early inklings of viable growth engines, please do not shift your product strategy just for the sake of doing so. You'll regret it.

Simplicity Wins

Similarly, to the point above, keep it simple. This is obviously key to external products, especially those that are consumer facing, but applies to your company's operations as well. You should try to reduce complexity in everything your company does--from your product development process to customer support. Overly complex systems slow everyone down. If you are constantly seeking the simplest, yet most impactful solution, that will permeate through your entire org and show in your end product as well.

Manual First, Tech Second

For my non-technical people, I know it can be frustrating to feel that you have an idea for a tech based solution that will have positive impact on your company's product, or your team's internal efficiency--but you're repeatedly told no or "maybe down the line". When your engineering resources are scarce, 99% of their time will be spent on the customer facing product. That's just how it goes. Simply telling your CEO that you think building X will improve a certain process by Y amount is not enough.

What can you do to give concrete proof that this will be the case? There are ways to validate your hypothesis with some grunt work on your end, that most likely doesn't require any initial help, or very little, from your engineering team. Focus on that. Design it, test it, and share the results. If you can show that you were able to get positive results with your manual process, that can impact the business in a significant way, then you'll have a much better chance of getting sign-off to build out a technical component.

Avoid Decisions by Committee

When your team is small, it can be tempting to feel the need to include every person in any decision you make for the company. This sets a bad precedent, and is a hard habit to break once people become accustomed to that being the case, and your team continues to grow. Of course, you should value their input, especially when it comes to your first few employees--who may have more context on why certain decisions may be made.

While your team should be made up of versatile role players, ideally they each will have some core expertise for which they were primarily hired. Empower them to make specific decisions, which will inevitably be wrong from time to time (hopefully not too often)--but everyone on the team will also be able to learn from.

Enjoy it :)

Building something from the ground up is extremely difficult. Most startups end up failing. At the end of the day, the new relationships you've built, the lessons you've learned and the stories you have will live on long after the start up is a success or failure. Every now and then, take a step back and cherish it. If you're thinking about joining a company in its infancy, take the leap. I promise it will be worth it.