Daily Technocrat | Musings on Technology, Startups, and Leadership

Services vs. Products For The New Startup

2013-04-29T16:45:00.002-07:00

Building on lesson #11 of my last post, I'm going to briefly go over some of the advantages of a service-first business, especially for non-technical founders. Service business, while often viewed as the red-headed step-children of the startup community, are actually very stable and can be nearly as profitable over time depending on the clientele and target market. Don't believe me? I'll explain.

A little background first. Having been around a state-run incubator that prides itself on its ability to create jobs and investment for a U.S. state in the northeast, I've always wondered why it, and others, focused so heavily on product-based companies. Software products can generate a lot of revenue, no one is disputing that, but nowadays they are also very, very easy to maintain, so the amount of actual jobs they create aren't as spectacular. Take Instagram for example, with millions and millions of users, they employed only a handful of people - just 13 at the time of their $1,000,000,000 acquisition by Facebook. Service businesses on the other hand make money from people's time charged to clients. More people, more profit. Or so the fundamental theory goes for those who charge by the hour. So I would imagine an incubator with a primary goal of creating jobs would focus a little more on the service offerings of their members rather than accepting mainly product-based companies. Perhaps they have other reasons for it. Who knows.

Anyway, back on subject. So, you want to start a tech company but have no coding experience? Think you need to lure a technical co-founder with a chunk of equity to create your product for free? Nope. If you think I'm a little biased against the idea of a technical cofounder, just know that I used to be one. So I'm speaking from my own observations and experience.

Service businesses allow you to explore your target market, learning the ins-and-outs, finding out what the client pains are and, best of all, get paid (handsomely in some cases) while doing it. Just look at 37 Signals. Founded in 1998, they spent six years as a service-only business providing web design before creating their flagship product, Basecamp. Offering services first enabled them to experience the pains of their clients and target markets first hand, leading to the future creation of world-class products like Campfire, Highrise, and even the Ruby on Rails framework which is used by millions of people and companies large and small every day. Could they have done this without their background in offering services? Probably not. I tend to think that for the simple reason their experience servicing clients is akin to a Ph.D. in entrepreneurship, from which they have gained worldwide renown.

Furthermore, there is little that cannot be accomplished with open source software nowadays. From implementing advanced Geospatial Information Systems to community portals to mobile data collection applications, open source can do just about anything. Learning how to set up a server is far easier than learning to code, and it can even be your segue to becoming technical if you aren't already. Google Apps are getting more mature by the day. App hosting services, like Heroku, are getting easier to use all the time as well. Do some research with what is already readily available. Do you really need a technical cofounder? Maybe, maybe not. I'm willing to bet not for most of you.

Lessons Learned in Startup Partnerships

2013-04-13T10:31:00.002-07:00

When Good Intentions Go Bad

I've spent months trying feverishly to "stick it out" with a business partner that has a decidedly different perception of my value, responsibilities, and contributions in an organization we've both spent a tremendous amount of time, money, and effort trying to grow. There's also been a bit of off-and-on conflict regarding our differing viewpoints on management, marketing, sales, and legal agreements as of late, so I have decided the best thing for both of us is that I simply walk away for the time being.

Herein I hoped to document some "lessons learned" for the benefit of anyone who has encountered something similar. These are not wholly the faults nor attributes of any single person, but mere guidelines of lessons learned from observance of others and my own self-introspection over the better part of the past year.

Lesson #1: Don't Over-Inflate Your Sense of Self-Worth. Also, Watch Your Public-Private Behaviors.

The fastest way to decimate the morale of a team is to take credit for their hard work in furtherance of your own career or personal image. Don't do it. Know who makes what contributions, track it even, and congratulate or recognize them for their efforts publicly. Saying a quick "thank you" in private and taking personal credit publicly will lose the loyalty and respect of the team quickly.

For example, if you started a company, even if by yourself at first, with just an idea - no product, no revenue, no experience, no management structure, not even a website - and then somehow use the team's, a partner's, or a co-founder's own contributions and expertise to justify an inflated value of said company for them to buy into either monetarily or otherwise, that will only earn you their abandonment as they will question why they need you at all to succeed. Especially if you were to spin their hard-earned contributions as solely or mostly your own efforts.

Acknowledge equally the contributions of all partners and don't require them to buy into the company based upon a lofty valuation which was only made possible through their own hard work and efforts to begin with.

One final note for this lesson: if you are called a "co-founder" behind closed doors but introduced as something else entirely at networking or other public events, that is a sign of a bad partnership.

Lesson #2: In a Startup, If You Aren't Coding, You're Selling.

Sure, administrative tasks may come up now and then to take care of, but sales and product development are the two core functions of a new company. Just because you don't know how to sell something, doesn't mean you should outsource sales to someone else. You need to learn...and quickly. The passion for the product idea comes from the founding team, and it is that energy and conviction which gets you those first few sales. Afterwards, once the ball is rolling, you can pass on your hard-gained knowledge and passion to another salesperson to carry the torch. But you need to lay a stable foundation first, leading by example.

Lesson tidbit: standardize your sales process early on with what works. Create scripts, plans, etc. for how a pitch should flow from start to end. Create and document different scripts for different situations - presentations, elevator pitches, on-site sales calls, off-site sales calls, networking events, employee interactions, etc. Update them as necessary.

On a similar note, if sales aren't progressing as fast or well as you had planned, blaming your personal inabilities to adequately market the product on the developer(s) is not the path to good team-building. Just because they can't (or won't) crank out new features every other hour doesn't make the product unsalable. That leads me to lesson #3.

Lesson #3: Features Alone Do Not Sell A Product.

Someone new to leading technology projects or tech startups will often attempt to pile features on a new product in a misguided attempt to "compete" with others already entrenched in the market. However, this only leads to feature bloat which can be crippling for a small company in terms of maintenance, scalability, and cost over time. Clients generally want ease of use, value, and reliability, not necessarily dozens of useless ancillary features that don't add much value directly to the core product (even if they pretend to at first).

Avoid the urge to add new features for every passing request or thought. Implement structured voting and prioritization processes to evaluate feature requests from both internal and external sources. Make those processes completely transparent to existing and prospective clients, but don't promise new features on every sales call just to impress potential customers. This sometimes gives the appearance of desperation on the part of the startup. In short, you don't want to be the type of salesperson willing to promise anything and everything to get a new client because, in the end, your whole team will end up paying the price for it.

Just to reiterate that last point, DO NOT PROMISE FUTURE FEATURES TO PROSPECTIVE CLIENTS. They will just keep waiting and waiting until that feature is implemented and perfected (which it almost never is) before they buy your product, if they do at all. This common trap will waste untold amounts of your team's time that could have been spent looking elsewhere for clients willing to buy your product right now. There are ALWAYS people willing to buy a new product out there, even if at a deep discount at first. The key thing is just to get them paying even a modest amount and then go from there.

Only novices believe you need to out-feature your competitors to sell a product and start generating revenue. Implement a paid beta program at a deep discount with limited functionality if necessary, but never, ever, promise future features on a whim at a sales pitch unless the client is willing to pay for the development of the new functionality out of their own pocket.

Another tidbit: if you give a client a limited trial or testing period, stick to it. If you keep extending it they will walk all over you to squeeze as much free use out of the product as they possibly can. Don't fear using the word "no" on occasion.

Lesson #4: Enforce Simplicity In Your Legal Relationships, But Always Protect Yourself.

Partnership agreements are unavoidable and quite simply a very wise thing to do, no matter how well you think you know each other. However, making someone adhere to an overly-complicated agreement or one that requires, for example, early co-founders to buy equity at a massively inflated or unjustifiable company valuation is simply not sensible.

The agreement should be as simple as legally feasible for the earliest co-founders and partners. For example, negotiate the equity split and a clear division of roles and responsibilities up front (not through lawyers who will siphon every dime they can from your capital reserves), then make it legally official in writing once the matter is settled verbally.

When deciding equity divisions, don't be greedy, but don't hesitate to ask for a share that is commensurate with your comparative level of experience, anticipated contributions, and expertise relative to the company's current state of product development, revenue, and existing management. Most importantly, implement equity vesting for ALL partners/co-founders over a few years. This protects everyone.

Furthermore, don't attempt to lure technical partners/co-founders with strict "developer agreements" that parcel out small chunks of equity at defined product milestones yet expect them to devote themselves wholly to the organization (unpaid, especially) as if an executive manager or salesperson. This sends mixed signals on how you value that person and what their role truly is.

If you treat a prospective partner or co-founder like an employee, and structure a legal agreement with them as such, you can't expect them to work out of scope of the agreement for free on good faith in hope that they will one day be accepted by the majority stakeholder(s) of the company as a full partner or co-founder. They will soon grow tired of fighting to become an equal entity in the company and just leave for greener pastures.

Lesson #5: Non-Technical Partners Need To Learn Some of the Technology. Technical Partners Need to Learn Some of the Business.

Even the most non-technical person in the early days of a tech startup needs to learn and understand some of the underlying technical functionality of the product they are expected to support, endorse, or sell. Having a decent familiarity with the generic software development lifecycle is also immensely helpful. This is because non-technical partners need to know and understand exactly what they are asking of their technical counterparts whenever they make a request of them for the product. You can't expect a technical partner to do all the work and implement new features at every beck and call overnight while you just sit back and deposit the checks. If you are a non-technical founder, take the time to understand the technical ecosystem of your company and how interconnected your product is within it, even if only at a high level.

Furthermore, non-technical partners need to learn how to put together adequate product requirements documentation at the very least. I'm not talking about hundred-page tomes of industry jargon, but simple lists of desired product functionality from a user perspective are useful. Wireframes, mock-ups, diagrams, use cases, etc. are too easy to put together collaboratively in a matter of minutes nowadays. There is absolutely no reason not to do this for every new feature request.

On that same note, technical partners need to understand the business perspective of the product. Without this, they will be coding in a void. Whether that means bringing them on sales calls at first or simply de-briefing them after every client contact, they need to be involved at a level that is probably deeper than what they are typically comfortable with.

Lesson #6: Dog-Fooding and Testing.

If you can't find a way to use your own product (or new feature), how could you expect future clients to use and find value in it? In the industry, this is typically called "dog-fooding", as in you need to "eat your own dog food" to fully experience the product (or feature) from a client's perspective. If you aren't doing it, then you aren't in a good position to validate its true usefulness and position in the market. There are special circumstances and caveats to this, but it still easily applies to 99% of the products out there right now.

Also on a related topic, never skip full-spectrum testing, which must involve technical and non-technical partners alike. I'm sure the high-speed technical partner is taking care of the unit testing (right?), but "black box" or user interface testing is equally as critical. Don't ever skip it and blindly sign off on new features without making absolutely certain they function as intended. Peer review by all partners, technical or otherwise, is essential. No client should ever see a new product or feature, even if it still carries the "beta" tag, that wasn't reviewed and signed off by the whole core team of partners.

Lesson #7: Implement Processes, But Prevent Bureaucracy.

In the early days of a new company, everything is shoot-from-the-hip and reactionary. This is more out of naïveté at first, but it's not scalable when business eventually takes off. From day one (or very soon thereafter) there should be simple processes in place for, at a minimum, requesting and accepting new product features, reporting and resolving bugs, product development and testing, light project management, client support, accounting and billing, and sales. This sounds like a lot, but it's not really. I'll go more into detail on this in future posts, but that should give you enough of an idea.

Don't, for example, grow your company into a bureaucratic monster, but do have a simple plan for every major action you take even if it is a simple workflow or review process between partners. Define it, document it, and stick to it.

Even though you need to implement standard processes, there is no need to generate hundreds of pages of documentation - this includes your business planning, too. Don't go overboard creating five year plans that won't maintain relevancy more than a mere five weeks out. Planning should be quarter-to-quarter in a startup with a very high-level set of goals for the future beyond the next year.

Lesson #8: Don't Do It To Get Rich Quick.

Do things for the love of doing them, not because of the potential payout they could bring. Pouring over financial projections to determine when your first million(s) will be made detracts from other aspects of the business. Sure, the thought of making it big is very alluring, but don't focus on it so much that you lose sight of the critical things you need to do to provide value to clients first before that happens. Startups shouldn't be treated like a lottery ticket, despite what you might read in the news or see in the movies. Ultimately, your customers will dictate if you make any money at all, so don't neglect them for selfish reasons.

Worry about keeping the company alive the first year, not what your revenue will be five years out or how much someone might be willing to buy you out for in four years. Those things will come in due time, but not in your first year (or two) of operations.

Lesson #9: Don't Expect Absolute Dedication From Others While Working On Other Unrelated Projects Yourself.

As a principal leader or founder in a startup, you are expected to have absolute dedication to the tasks at hand to see your nascent organization through some of its most trying times. However, if you become distracted by another unrelated project or endeavor, especially early on, those partners or co-founders whom you expect to follow you whole-heartedly into the abyss of the market will not feel the need to dedicate themselves entirely to the mission of the company. Asking partners to work full-time without compensation on something while you, as a principal leader or founder of the organization, undertake other unrelated projects does not engender confidence in your motives or abilities within the startup team, or investors for that matter as well.

If you set out on something, as a leader you must see it through. Do whatever you can to not get distracted during the crucial client discovery, market validation, and product development phases of a startup company. Adopt a mission-first mentality. As the principal leader or founder of a startup, every moment you can spare should be focused solely on building the company, not starting and working on unrelated side projects however more interesting or lucrative they may appear in comparison.

Lesson #10: Be Flexible.

Just because something worked a certain way ten or twenty years ago, doesn't mean it will (or should) work the same way today.

For example, don't hesitate to use and enforce the usage of the latest in free collaborative technology the internet has to offer. Nowadays, requiring daily trips to a centralized office are a waste of everyone's time and the company's scarce resources. I'm not saying face-to-face communication is without merit, but it is not required on a daily basis to accomplish the goals of your startup.

Not only that, but permanent office space is generally a waste of money for most brand new companies in the technology sector, at least for the first six months to a year of operations. Obviously, there are exceptions, such as companies requiring lab space or performing manufacturing or hardware intensive work, but software can be developed and services rendered from just about anywhere nowadays.

Around two to three days per week I have found to be an optimal mix of on-site/off-site work for most software or service oriented companies. But, again, adjust as conditions dictate. Some companies have leaders who are perfectly comfortable working and managing others entirely virtually anywhere in the world, whereas others are more old-fashioned, many times to the detriment of team morale, work-life balance, and productivity.

Lesson tidbit: When you are a small company just starting out, you have to be willing to go the extra mile to attract talent, including giving them the option and flexibility to work virtually. That way, a new company in, say, the middle of Pennsylvania can compete more effectively with rivals in New York City or Silicon Valley.

**Lesson #11: Non-Technical Founders Should Validate Their Ideas With Service Offerings First, Then Build a Product.**

Contrary to the "if you build it, they will come" mentality of many startup leaders, I firmly believe that non-technical founders, if wishing to create value in the company before bringing on partners, should try and validate their idea through a service offering first.

For example, if you are looking to create a data collection product, there are literally hundreds of free or nearly-free utilities (e.g. Google Apps) that can be used to patch together a manual solution first. Once that is done and the idea is validated and generating revenue, then bring on a technical person to automate and enhance everything. Not only will this be more attractive to technical partners and investors, but it will give the non-technical founder an upper hand in equity or investment negotiations with those people as well.

The lesson here is: don't immediately look to a technical co-founder as a silver bullet for revenue growth, especially when your idea is not yet validated and, therefore, subject to large amounts of change from week to week while adapting to the market.

Non-technical founders who strive to find out how their idea will be received by potential clients through an initial service offering not only get to learn some of the crucial sales and marketing processes along the way, before development of a full-fledged product, but also increase their odds of success over the long term exponentially.

In Summary...

Starting a company is as much about managing relationships, being willing to learn new skills, and team building as it is anything else. Don't neglect these aspects. If you are experiencing some of the more negative things like I've mentioned above, know when to draw a line in the sand, or, at the very least, sound an alarm and attempt a change in direction if all parties are willing or able. Whatever you do, don't let a bad situation linger for months (or years) on end, because it will only get more complicated and, ultimately, detrimental to everyone involved.

A Technical Co-Founder in an Enterprise Software Startup

2012-12-13T19:50:00.001-08:00

As a nascent technical cofounder of a local enterprise software startup, I've made several revelations regarding the life and role of a chief tech person in a brand new startup.

Much of this may not be new to some of you, but I choose to share this for a number of reasons. Particularly because it is the perspective of a somewhat new entrepreneur with a decade of experience working in the government and private enterprise technology sectors. I've essentially successfully leapt from the bellies of beasts into the fires of the free market. Uncommon? Perhaps. Unique? Not really. But, alas, I hope you find some nuggets of usefulness in this post.

I'll break this down list style as I'm not a fan of anecdotes run amok:

1. Don't try to do it all. There is only so much time in the day, and switching back and forth between sales and coding is suboptimal. The laws of task switching alone consume hours on end. If you can't get at least 4 to 6 hours per day completely distraction free, consider contracting out at least a good portion of the work. Enterprise sales cycles require a longer, larger degree of interaction from all the partners of a new startup. That means if there are only two of you, sales is a first priority after your initial functional release of a product. Enhancements will come slower after your first release due to this new sales effort, so contract out work where feasible to stay on top of the game.

2. Don't neglect the big picture. This applies to both the company and the software. Understandably, time is of the essence in a startup but, remember, you will eventually pass that mess of tangled spaghetti you call a system onto someone else at some point to maintain. Code with the bigger picture in mind. Keep things abstract and orthogonal, keep your interfaces clean and thought out, code can and should be self-documentable to the best degree possible, make detailed notes, test to the degree that time allows and never skip it. Don't cut corners if you don't have to, especially in the enterprise software market. These clients often expect much more than the consumer market. They expect value from day one.

3. Don't undervalue your product. Think of a number you'd like to charge. Now triple it. Go out and tell people that is your monthly price or price per user. If they don't even wince, go with it (or maybe even go higher). In my experience, they hardly ever complain about price - only about value.

4. Integration is paramount. This is the enterprise market after all. These people have systems from the 80's running their entire payroll division. They want your product to work with it. You need to keep your product flexible for integration, as much as possible. Integration is the number one request of every client I've talked to. That leads me to my last one for today, number 5.

5. Don't be afraid to offer accompanying services. Because of the low-volume, high-margins type of work in the enterprise market, these clients expect top notch service. I'm not saying do it for free, but expect to offer it if you really want to find a competitive edge against the bigger companies entrenched in this market. I can't tell you how many times I've heard "we like your company and product most of all because you are willing to work with us, even if you are charging us for it." Revenue is revenue after all, and I'm willing to bet the largest amount of customization requests will be integration with existing systems. Don't let it side track you and distract you from other clients, however. There is a balance to maintain.

That's all I have for right now. I anticipate I'll revisit and revise this post from time to time as my experience progresses, so stay tuned. What are your thoughts on this?

Why does government software suck?

2012-07-30T10:51:00.003-07:00

It's been a while since writing last and, for that, I apologize. A lot of things have happened and I notice that the previous article about the Retina MacBook Pro was a stellar hit amongst you Netizens.

Regardless, I want to get to the bedrock of why I created this blog. While the gadget posts are fun and all, I have a real issue I would like to talk about today. One which I know a lot about actually: Government Software.

Of all the advancements made in the past few decades, they always seem to leap directly over the largest single buyer of information technology in the country; that being the U.S. Government. While some generic form of risk aversion plays a big role in why the government is often a laggard in adapting to innovation, particularly in these modern times, the issue is actually much, much deeper.

Personally, I believe the issue to be a deeply ingrained organizational culture in many federal departments, though not necessarily all of them. There is also a known lack of interest coming from the "Millenial" generation, otherwise known as the "digital natives," in civil service due to the heavily structured, stuffy perception of government work. And, well, it is exactly that. How can the government compete with the likes of Google or Microsoft for fresh talent? It can't.

Furthermore, the promised "tsunami" of retirements from the "boomer" generation, now doggedly holding onto their positions atop the food chain, has not yet materialized while, simultaneously, historical cuts, freezes, and restrictions on hiring have been enacted in just about every part of government. Worsening things even more, the "great wall" that is government human resources has become one of the new wonders of the bureaucratic world. Of those trying desperately to attempt to climb it, most usually succumb to its vast nothingness of endless application requirements, meaningless jargon, canceled positions, empty responses, and, dare I say it, occasional instances of cronyism.

So, you may ask if you have stayed with me thus far, how does this relate to government software? Well, I'll tell you. Too many of those who cling to their perches atop decades of civil service do just enough to protect their jobs, but little more. Risk is a four letter word, after all, and, with all this recent political instability, no one is willing to tolerate or even consider it. This attitude reverberates through all parts of government in the affected departments, embedding itself in the culture of the organization. This means a new wave of potential civil servants with fresh ideas and eager minds are stopped dead in their tracks. Even if they do get through to wall and into the belly of the machine, they are subjected to a mind-numbing bureaucratic indoctrination which is unparalleled in our modern world and would even make a North Korean dictator wince. Many have tried, and failed, to correct this, but the bureaucracy is seemingly insurmountable, even for a President. Many eager leaders have come and gone, with little to show for all their time, at least at the ground level. Sure, those national initiatives make a great sound bite, but those down where rubber meets road and the public beneficiaries of some of these technological "improvements" aren't seeing anything vastly different or better for the most part.

Now, don't get me wrong, the "boomer" generation has built the bedrock of the very society we live in today. It was their "fresh ideas" in the 60's and beyond that created the world's first electronic health record, some of the first national scale software systems and electronic databases, computing advancements, networking technology, THE INTERNET, global positioning, space travel, etc. But, now approaching their retirement years, much of that enthusiasm has markedly waned even while they still hold their positions.

All I'm trying to say is this: poor government software has less to do with a lack of ability or technology, and more to do with a lack of willingness and fresh ideas. It won't be until the next generations, of both people and private sector solutions, are welcomed at the doors of government that things could change for the better. But that will take political stability, new perceptions of productivity in a modern workplace, and an acceptance of some level of risk for the sake of innovation.

Hands On With The 2012 Retina MacBook Pro

2012-06-16T16:24:00.000-07:00

When I logged into my new Apple account on Friday, June 15th, I was pleasantly surprised that my new MacBook Pro with Retina display was due to arrive on that very day - a full week ahead of schedule. As this is my first Apple purchase in, oh, two decades of using PCs, I took several pictures and went right to work putting the system though its paces. Here I will detail some of what I have discovered and continuously update this post as new items arise.

The Unboxing

As I stated in a previous post (at least I believe I did), Apple was very courteous and efficient in upgrading the shipping speed of my device for free; from 5 to 7 days down to 2 or 3 days. After all was said and done, it only took four days total to travel from the factory in China to my doorstep.

People who say Apple pays attention to even the smallest details that affect user experience are completely correct. The box in and of itself was a joy to pry open. I won't go much into details since most everyone knows this stuff already; but, as a lifelong PC user, I was impressed.

The first thing I noticed is the slim, minimal design. Very aesthetic and pleasing to the eyes. The screen is a bit glossier than what I had anticipated, but we'll see how it looks when I turn it on before passing judgment. The MagSafe2 connector is surprisingly strong (in a magnetic sense). Coming from a world of loose PC power dongles, this was pleasing to me.

First Bootup

A quick single press of the power button (no holding down for X seconds like some PCs), and its off and running. This thing boots up FAST. I have a PC laptop, purchased new in December 2011, with a quad-core Intel Core i7 (Sandy Bridge), 8GB DDR3 1600Mhz RAM and a 256GB Crucial SSD - but it still doesn't hold a candle to this thing. Blazing is the word.

The Display

This is probably what most of you are waiting for. Well, the hype is true on the Retina display for this MacBook Pro. Though the screen is a little glossy (as seen in the image above), it still manages to stay readable in semi-bright lighting. It's better than most, but I have owned a PC laptop with an anti-glare screen that was noticeably less reflective. However, the resolution, contrast and color is mind blowing. The icons appear as if ready to pluck directly from the screen. Such detail I have never seen before in a laptop. Simply amazing. Apple has truly redefined "high definition" with this display. Ok, ok, enough gushing. My only complaint is that smudges from the occasional touch of a finger are very apparent. Keeping this thing clean will be difficult around kids.

More...

Well, I'm stopping here for now, but will be updating this post (or just creating new ones) in coming days as I acquaint myself with the new world that is Apple. I thank you all for joining me on this journey.

Retina MacBook Pro vs. Windows PC

2012-06-13T13:19:00.003-07:00

First time Apple buyer here, long time Windows PC user. With this new Retina MacBook Pro, I believe there is a certain value in Apple hardware and software that has never really previously existed - at least from a Windows PC user perspective. This powerful new machine boasts the latest and greatest technology in a highly portable form factor, with a functional yet aesthetic design that is unmatched in the market to date.

Many have said, and I can agree, that, from here on out, there really are no comparisons between Apple and Windows PCs because the divergence is very clear: Apple goes after the high-end of the market, Windows PCs are for everyone else. After sitting on the sidelines trying desperately to justify the price-to-performance ratio of an Apple computer vs. Windows PC, I finally "get it" (as my lifelong Apple-using colleagues tell me).

Mostly, however, the biggest game changer for me was witnessing the declining quality of PCs on the market. Having owned PCs from HP, Dell, Samsung, Asus, Compaq, Lenovo, etc. - they have never really lasted more than a couple years at most and almost always had driver, battery, memory, touchpad/keypad, cooling system, or other issues during the entire time I owned them. I was envious of my Apple counterparts who hung onto their machines for more than a half decade without so much as a hiccup and could resell them at a respectable price whenever they wanted.

Oh, and customer service, too. It simply doesn't exist in the PC world in the same way it does for an Apple user. PCs fall apart so quickly nowadays due to their "quantity-over-quality" approach and yet their support is lackluster at best. Dealing with overseas call centers trying to get a warranty honored or a simple battery replaced is tantamount to torture in some circles. Not so with Apple, at least in my nascent experience thus far.

Well, I made the leap. I bought this new Retina MacBook Pro the first day it came out and I'm looking forward to using my first Apple purchase for work and play. What are your thoughts on the subject, especially from the fellow lifelong Windows users out there?