It is Martin Luther King day, and I am fortunate to have a holiday. However, I haven't lost sight of my goal of becoming an entrepreneur and founding a startup, so I'm reading The Lean Startup.
Chapter 1: To be an Entrepreneur, you need to Build a Product that will Sell
I gathered the salient point that evaluating ideas locally is self-deception. That point applies to me as a developer who can implement the entire stack of a significant application without hiring external software or data engineers. Going in, I am thinking: If I could only meet a counterpart in financing that could help direct me through a business plan and raising capital. Suppose I could only find like-minded entrepreneurs incredibly gifted at sales and share my vision. Then, I could launch a startup.
That's a foolish sentiment. Instead, I see that the most important goal of implementing a startup idea is turning the execution of an idea into a profitable organization.
It's not only about being able to execute. Lord knows the startup graveyard is filled with codebases of beautiful code, and applications run fine, but no one wants. So managing and validating that the product serves a customer's need is a matter of collecting and validating it.
Back to the sentiment I had back in May of last year, I wanted to use this platform for blogging about my achievements as a computer scientist and as a sounding board for my ambitions to run my own company for the greater good.
As I am trying to think about a startup that will change people's lives for good, I need to think about customers whose purpose is to help people. Exercises in discovering what to build motivate ultimately building solutions. Maybe I'm foolish, but I hope that if my ideas are organized, I'll be ready someday when I have an opportunity to act on those ideas.
What about the hospital that needs to be more efficient in collecting bills from the Center for Medicare and Medicaid Services (CMS)? How would that translate into applications I could build?
Integrate medical billing and SSAS marketing using secure, turnkey solutions that a hospital can easily integrate into its back office. For example, could we use marketing applications like Melissa Data, Acxiom, or even Salesforce to streamline connecting indigent accounts to state and federal medical payers?
What about utilizing AI and geolocation applications to build solutions that address homelessness and chronic mental illness? Could hospitals de-centralize more efficiently and do a better job of caring for their communities?
Chapter 2: An Entrepreneur isn't Just someone who Founds a Company
As I plow my way into Chapter 2, I find the environment more accurately describes my "real-world" career rather than the fantasy one that is "blogging on owlmountain.net."
I work as a developer in the corporate world, and transitioning to a true entrepreneur would be a challenging endeavor. Not that I wouldn't want to, but I would need to build a core group of colleagues who can build out the things I cannot do on my own.
The next chapter addresses "Intrapreneuring." Again, it's an easy enough concept: What about building a team within an existing company that can hold to entrepreneurial values?
The five-person Intuit team that built SnapTax was just one of those teams. It could be a fantasy description to sell books, but I am impressed that they could do it. Not that they could do it with five people, but they could get a management structure that looks at millions of dollar team budgets blithely to carve them out a team and budget to build a product within an entrepreneurial pod.
I agree wholeheartedly with the Five-Person Rule (that isn't in the book, but it should be a maxim). However, most companies most significant problem is that leadership and middle management overstaff their teams and fail to build cohesive systems to deliver value.
Corporate entities can't build five-person teams because they are usually constructed into silos, where a five-person team means five Software Engineers or five Finance Analysts. So if someone at a high level has an idea, they put together a five-person software engineer team and construct another silo.
A Five Person Team can be an Intrapreneurship team that starts with the ability to own and manage their budget - and be accountable in the same way a startup is accountable. My ideal Five Person Team:
A Finance Analyst manages the Budget and Revenue of the Team
A Lead Engineer Capable of Building the Product
A QA Engineer Responsible for testing
A Support Engineer Capable of Targeting Feedback from the Customer
A Customer Success Manager talking directly to the customer
It's a great core that is cross-functional from the beginning. The team is responsible for building a product, and each team member has unique skills. Most HR organizations would cringe at a team like this because they want to get economies of scale, share the finance person, and then add more engineers. The most common corporate thinking fallacy is that more engineers are better. More engineers are generally worse. Better engineers are better. More team autonomy is better, and if the team is accountable to the budget and revenue, then you have a good team. Start there.