Over the years I have heard comments like, “We operate like a startup,” “We act like a startup,” and “We are an overnight success that was 10 years in the making.” These statements are often euphemisms for “We are small and not growing as quickly as we would like.”
There are numerous estimates of startups in their first few years. One of the best descriptions that I have found is from Failory, but Investopedia and LendingTree have similar but differing takes on the statistics and root causes. All three articles linked to are worth reading. The net result is that the outcome of failure is much greater than the outcome of success, especially over time. So, “acting like a startup” is not necessarily a good thing even when it is true. You want to act like a successful startup!
Understanding the data and various causes for success and failure are great inputs to business plans. I have been a principal with successful startups, both early employees and founders. Understanding the data and various causes for success and failure are significant inputs to business plans focused on long-term success. As a Founder, there are a few points that I believe to be key to success:
- You have specific expertise that is in demand and would be valuable to an identifiable number of prospective customers. How would those customers use those skills, and how would they quantify the value? That understanding provides focus on what to sell and to whom.
- Have a detailed understanding of the market and key players to hone in on a niche to succeed.
- Understand your strengths and weaknesses, and then hire the most intelligent and most ambitious people whose strengths complement your strengths and weaknesses.
- Understand how you will reach those potential customers and the messaging you believe will compel them. Then, find a way to test those assumptions and refine them as necessary. Marketing and Lead Generation is very important.
- Have a plan for delivering on whatever you are selling before you get your first sale. A startup needs to develop its track record of success, beginning with its first sale.
- Cash flow is king. It is far too easy to run out of money while looking at a balance sheet that seems excellent because of receivables. Understand what matters and why it matters.
- Founders need to understand the administrative side of a business – especially the financial, legal (especially contract law), insurance, and tax side of things. Find experts to validate your approach and fill in knowledge gaps.
- Consistency leads to repeatable success. You standardize, optimize, and automate everything possible. Wasted time and effort becomes wasted opportunity.
- Finally, there needs to be sufficient cash on hand to fund the time that it takes to find and close your first deals, deliver and invoice the work, and then receive your first payments. That could easily be a 3-6 month period.
Those are the foundational items that are reasonably tangible. What is not as concrete but equally as important are:
- Having or developing the ability to spot trends and identify gaps that could become opportunities for your business.
- Having an agile mindset allows you to pivot your offerings or approach to refine your business model and hone in on that successful niche for your business.
- Foster a sense of innovation within your business. Always look for opportunities to deliver a better product or service, improve the efficiency and effectiveness of your business, and create intellectual property (IP) that adds long-term value.
- Focus on being the best and building a brand that helps differentiate you from your competition.
- Become a Leader, Not a Manager. Create your vision of success, set expectations for each person and team, and help eliminate roadblocks to their success. Trust your team to help you grow, and replace members quickly if it becomes clear that they are not a good fit.
As Steve Jobs once said, “It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”
Winning is hard, so focus on the journey. Making your customers’ lives easier and allowing your employees to be creative while doing something they are proud of will lead you to your destination. But, when things start going well, don’t sit back and convince yourself that you are successful. Instead, continue to focus on ways to improve and grow.
Success means different things to different people, but longevity, growth, profitability, and some form of contributing to a greater good should be dimensions of success for any vision.
Long before I began consulting, I was developing new applications for a Marketing company. Nearly everything was built from the ground up at the time and there was very little reuse. That changed over time as I developed reusable functions and eventually created a “standard system” that led to a significant reduction in development time due to reuse. Throughout this multi-year period I had an unplanned but valuable assistant – “Wendy Sue.”
My user interfaces were generally liked due to layout, workflow, help screens, etc. But, a new hire in the Customer Service team was consistently running into problems. I was young and one of my first interactions with her probably went something like this, “Why would you do it that way? That doesn’t even make sense? Have you ever worked with computers before?”
She began crying. I felt like a jerk as my frustration began to wane. Days later, I realized that Wendy Sue was really a gift and not a problem. She had an incredible knack for finding obscure flaws and breaking things. I embraced this, bought her lunch, and asked her if she would be willing to help make my software better. She was excited to be able to help, and eventually we laughed about our initial encounters.
Wendy Sue and I had become allies in a quest to create custom software that provided a better, problem free user experience. Nothing was taken for granted. Everything became more robust. And surprisingly to me, these changes were appreciated by everyone, not just Wendy Sue. She helped me become a better programmer and analyst, and I provided her with an experience that led to her becoming one of the first Quality Assurance Analysts in the company. It was a win-win.
There is often a considerable difference in the expectations and ways that Gen Z, Millennial, Gen X, and Baby Boomer users’ interface with applications. Creating a one size fits all application is far more challenging today because of this simple fact. But, it is essential to success.
People today tend to move on to something else when their experiences fail to match their expectations. Investing in “Wendy Sue proofing” your systems can become a competitive advantage. I have long held the belief that, “People buy easy.”
If one person encounters a problem then others will likely follow unless a remedy is implemented. It is more work, but the result can be increased satisfaction that results in increased usage and loyalty. That seems like a good tradeoff to me.
What are your thoughts?
This is an extremely powerful Teaching and Learning Experience Platform (LXP) that I have been using for close to a year now. It is amazing how a better approach to learning leads to better retention and understanding.
“Tell me and I forget. Teach me and I remember. Involve me and I learn.”
Life is filled with unexpected events. In most cases, we make tiny adjustments and carry on. We trip. We stumble. We pick ourselves up and pay closer attention to where our feet are taking us.
Others force us to rethink what we previously took for granted. These are the big events that come out of the blue, grab us by the collar, and give us a good shaking. The death of a loved one. The sudden loss of a job.
And then there are the colossal events that not only change us individually, but the world we live in. In my lifetime, I’ve seen my fair share of these earth-shakers. The assassination of John F. Kennedy. The legalization of gay marriage. The fall of the Berlin Wall. The election of the first…
View original post 933 more words
Regardless of your position or role, panic is not a good problem-solving tool. It is especially bad when you are in charge of people, or when you are brought in for your expertise. Panic leads to a myopic view of the problem, and that hinders creativity.
The point in my career when this became readily apparent is when I was working for a small software company. We had a new product (Warehouse Management System) and were launching our third deployment. This one was more complicated than the rest because it was for a pharmaceutical company. In addition to requirements like refrigeration and lot control, there was a mix of FDA-controlled items requiring various forms of auditing and security as well as storage areas that were significantly smaller than previous installations. It was a challenge to be sure.
During this implementation, a critical component, “Location Search,” failed. There were about 10-12 people in the “war room” when my boss, the VP of Development, began to panic. He was an extremely talented person who normally did an excellent job, but his reaction began negatively affecting the others in the room. The mood quickly worsened.
Partly because I did not want to be stuck there all weekend, and mostly because I wanted this implementation to be a success, I jumped in and took over. I asked my boss to go out and get a bunch of pizzas. Next, I organized a short meeting to review what we knew, what was different from our prior tests and asked for speculation about the root cause of this problem. The team came up with two potential causes and one potential workaround. Everyone organized into three teams and we began attacking each item independently.
We ended up identifying the root cause which led to an ideal fix a few days later, as well as a work-around that allowed us to finish the user acceptance testing and go live the following day. A change in mindset fostered the collaboration and problem-solving needed to move forward.
But, this isn’t just limited to groups. I was a consultant working at a large insurance company where I was on a team redesigning their Risk Management system. We were using new software and wanted to be sure that the proper environment variables were set during the Unix login process for this new system. I volunteered to create an external function that was executed as part of the login process. Trying to maintain clean code, I had an “exit” at the end of the function. It worked well during testing but once it was placed into production the function immediately logged people out as they were attempting to log into the system.
As you can imagine, I had a sinking feeling in my gut. How could I have missed this? This was a newer system deployed just for this risk management application so there were no other privileged users logged in at the time. Then, I remembered reading about a Unix “worm” that used FTP to infiltrate systems. The article stated that FTP bypassed the standard login process. This allowed me to FTP into the system and then delete the offending function. In less than 5 minutes everything was back to normal.
A related lesson learned was to make key people aware of what just happened, noting first that the problem had been resolved and that there was no lasting damage. Hiding mistakes kills careers. Then, we created a “Lessons Learned” log, with this as the first entry, to foster the idea of sharing mistakes as a way to avoid them in the future. Understanding that mistakes can happen to anyone turns out to be a good way to get people to plan better and then keep them from panicking when problems occur.
Staying calm and focused on resolving the problem is a much better approach than worrying about blame and the implication of those actions. And, most people appreciate the honesty.
Too often people, including Consultants, spend time trying to solve the wrong problem due to having incomplete or incorrect information. Once I was investigating a series of performance problems and unplanned outages that were assumed to be two separate problems. As I gathered information several people provided anecdotal stories of anomalous behaviors in a variety of systems, speculation about the “real problem,” and discussions about “chasing ghosts” during previous attempts to resolve the problem.
I remember stating that I was there to solve a real problem having a serious negative impact on production and that it was not my intent to chase ghosts or do anything else that would unnecessarily waste time. Next, I outlined the approach I would use to make a Root Cause determination, and that we would reconvene to discuss the real problem and potential solutions. A few people scoffed and felt that this was a waste of time and money.
The process followed was simple, structured, and logical. It took everything that was known to be true and mapped it out. I looked for patterns, commonalities, and intersections of systems and events. Within two days my team and I had identified a complex root cause involving multiple components, which we demonstrated would reliably reproduce the symptoms that our client was experiencing. From there we worked with their teams to make minor network changes, system configuration changes, and several small application changes.
By the end of the second week, they were no longer experiencing major slowdowns or unplanned outages. Each outage cost this company tens of thousands of dollars in lost sales due to the time-sensitive nature of their product. Within one week they had recovered the cost of hiring me and my team. What stuck with us was how many really smart people “believed in ghosts” and failed to focus on the information that they already had.
A few years later we decided to create a white paper to potentially help others in need of a simple structured approach. Below is a link to that white paper, which was written by one of the top people on my team. We received very positive feedback at the time so it seemed that this could potentially still be useful today. Please take a look and let me know what you think.