Migration from Early Market to Mainstream Market

Attached is a document which I intend to submit to my CEO regarding the mistakes I saw in our production development and marketing strategy, based on the teachings in Crossing the Chasm.

---

Company X: Crossing the Chasm
Migration from Early Market to Mainstream Market

I have been reading this book about “Crossing the Chasm” by Geoffrey A. Moore, which discuss about the strategy of bringing your product from the early market (the visionary & technologist) to the mainstream market (the pragmatist & conservative). The gap between this two market is known as the chasm. The bell curve chart shown below is the Technology Adoption Life Cycle.


(Ref: Wikipedia)

I believe Product X had somehow managed to conquer the early market, where we have some strong sales in the early days. After which we fail to cross the chasm to the mainstream market, thus leading to lesser deals and ultimate product cold storage. If this were our problem, we would need to identify the right strategy to help us to cross the chasm.

According to Mr. Moore, this first thing we need to do is to secure a beachhead. Like the D-Day, in order to get to the rest of Europe (the mainstream market), we would need to conquer the beaches of Normandy (the beachhead). In order to secure a beachhead, we need to become the market leader.

Pragmatists are people who only listen and talk to their own kind, such as doctor talks to doctors and lawyer talks to lawyers. To win the heart of pragmatist, we need market leadership to establish strong word of mouth among their social and business groups. Now we are trapped in a Chicken and Egg scenario, where we need to become the market leader in order to enter the mainstream market. At the same time, we need to enter the mainstream market in order to become the market leader. The good news is every Chicken and Egg problem has a solution for it, else no new startup would have succeeded.

Since we have limited resources, we would need to be FOCUS. Choose a niche market and try to be the market leader. For Product X, we could not afford to be the market leader in DMS or Workflow. But, we could segment the market and concentrate on a specific market segment. For example, we could choose to become DMS leader in market segment such as Banking, Insurance, Factory, Law Firm, Pharmaceutical and etc. Market segment can be selected based on our existing customer base and evaluating competition. No matter how successful a competitor are, they could not possibly cover all the grounds. Our objective is to conquer more than 70% of our target segment where people would relate the specific segment with our product name. At this moment, we are targeting niche market segment with strong Product X footprint and weak competitor presence. We need to target a niche market, force our competitors out and use it as a base for broader expansion. The niche market will be our beachhead to enter the mainstream market. The niche market will be our strong reference to generate a strong word of mouth. The more tightly bound the market is, the faster messages travel by mouth.

The key to successful market leadership is FOCUS; thus we need to be market oriented rather than sales oriented. Most of the time we are tempted to become sales oriented, as this is where the immediate money is available to cover our bottom line. Being sales oriented would actually take our “Crossing the Chasm” effort a few steps back. Sales oriented would means diversification, where we would take any projects in disregard to its market segment or product segment. With our limited resources, we could not afford to cover all the grounds. Thus we would need to be market oriented, focusing our resources in strengthening our product and attack strongly on our target market segment. The time for diversification is after we have achieved market leadership in the mainstream market, when we have the proper resources to expand and conquers more market segments for more opportunities. It is mentioned being sales oriented when crossing the chasm period is fatal. If we were sales driven, we would not cover enough ground for the word of mouth effect. Pragmatist want to buy from market leader, make sure you are the leader in your niche market. Why do we want to be market driven? For product leverage, word of mouth effectiveness and perceived market leadership. The best example for this strategy is Apple Macintosh, where they build machine and application for graphic department (niche market). Once they secure their beachhead, they start to target the nearby market.

There are many strategy and elements from the book that I would not be covering, such as utilizing different strategy to attract different group of customers at different stages. I am not a businessperson nor knowledgeable in marketing and sales, but I found the strategy proposed by Mr. Moore rather interesting and could be beneficial to us.

Basic Policy when Positioning an Employee

I wrote the following when I was asked by the CEO to give my suggestion on Technical Team Restructuring. At the end, I think no one give a damn. I remove the proposed organisation chart and responsibilities, which is pretty boring, but focus on the juicy part.

---

Below are some basic principals applied when positioning an employee:

1. There must not be a “Years of Experience” attached to a certain position. It is not necessary a 10 years programmer is better than a 5 years programmer. Though experience is important, but it does not translate to capability and productivity. It is a sad scene to turn a way a young and capable person as Project Manager just because he is not old enough. Experience does matter, but it is very subjective as well and the number of years does not reflect the real value of experience itself.
2. Career advancement does not necessary proceed in sequence. It is not necessary for a Developer to become a Lead Developer first before being promoted as a Project Manager. If his peers and supervisor acknowledge an employee’s capability and contribution, why give excuse for not promoting him to his much-deserved position.
3. Salary gap will not be barrier in career advancement. Even though a Developer’s salary is just a mere RM 2000 per month, salary gap shall not be used as an excuse to postponed his promotion to a Project Manager position with a salary of RM 5000 or more. If an employee is reviewed as capable and ready for the position, there shouldn’t be anything to stop him from taking up the new challenge.
4. Certification should be treated as complementary, not mandatory. The best programmer in the world might not hold any certification, or he could get all the certification in the world if he is willing to spend the money taking the exams. There is no guarantee that a MCSD (Microsoft Certified Solution Developer) is better than someone who learns programming by his own. But MCSD does promise a minimal standard in the holder’s skill.
5. Besides supervisor appraisal, peer appraisal is equally informative. Those who work together have a better understanding of its team member’s pros and cons, which might be missed by the immediate supervisor. If most of the colleagues agree Person A is a capable person with high programming skill, probably the supervisor should have a second thought. It is reasonable to promote someone who are recognised and appointed by his peers.
6. No new employment for technical position shall be done without a technical test. Everyone can claims that they know Oracle or work on Oracle for 7 years, but we need a test to really evaluate their actual knowledge and skill. If a test is not possible, they would need to demonstrate in technical detail of their past projects in the present of a technically qualified staff with the required domain knowledge. No technical person should be employed just by holding on his words.
7. We don’t recommend creating more position than necessary, if the position does not serve a distinctive purpose. For example, the current responsibility of Developer and Application Specialist seems similar and does not have a distinctive difference. For the purpose to satisfy the needs for career advancement space and differentiation of contribution and experience, each position could be attached with a Senior prefix.
8. Transparency for the result of evaluation and appraisal. Every employee should be informed of their appraisal score (on the scale of 1-10) and analysis of their strong points and weaknesses. This is to ensure the management is professional and fair in the judgement process, as well to let the employee to understand their weaknesses and improve on it.
9. For employee who scored low (less than 3 points perhaps) in the appraisal process, we would need to issue them warning letters and help them to improve themselves, or they would be asked to leave. The appraisal score shall directly affect the reward and bonus. Employee who scored very low might not be eligible for bonus.

Transition of culture from System Integrator to Software House

Attached is the content of a document that I wrote to my CEO when I decided to quit, out of frustration and disappointment with the company's culture. I would say the company had a less technical/development centric culture, more sales centric. She is like a System Integrator trying very hard to be a Software House. Like a typical IT Company run by a sales person, the management always focus on short-term sales solution than long term product development. I am not saying sales are not important, but the following is just my view as the developer at that point of time. I was trying to do some good for the rest of the developers there before my last day :)

---

Company X: An Employee’s Perspective
Transition of culture from System Integrator to Software House

Company X is a System Integrator and Software House, that’s how she wanted to portray herself to others. But the fact is COMPANY X had her System Integrator root so deep in the corporate culture that no matter how hard she try to be a Software House, she will probably never become one.

What basically made up a software house? 4 Elements: Product Vision, Elite Software Programmer, Continuous Effort and Good Tools.

COMPANY X have a strong product vision, which is a fantastic thing to have. The management has strong will to bring the company one step further. But wanting to do is one matter, the planning and perseverance to make the vision a reality is another matter. We need the other 3 elements to realization of the vision.

COMPANY X have a good team of programmers, but it had a corporate hierarchy of a non-software company. In a COMPANY X’s division, it had a Division Manager, Product Manager/Software Manager, Programmer/Technical Staff. Basically, the idea was to have the Product Manager to lead the Programmer in Product Development. What is wrong with this setup? Firstly, where is the Technical Lead/Technical Director/Chief Software Architect/Chief Technology Officer? Doesn’t a Software House need someone technically sounds to lead its horde of Programmer Army? It lacks a person with a strong technical knowledge to lead a team of programmer in design and development of a product. Isn’t that the job of a Product Manager? Not quite. A Product Manager might not be a person with strong technical background, but he understands what the product supposes to be, thus able to create a product road map. A Technical Lead shall translate the roadmap into technical detail and lead the team into product development. You can’t really expect a person without a strong programming background to lead a bunch of good programmer, as they would be much communication barrier and perception gap. Every successful software house has a very influential Software Architect. For example, Bill Gates from Microsoft steps down as CEO of Microsoft and appoints himself as Chief Software Architect to overseas the product development. Jerry Yang is Chief Yahoo where he hold the most important and influential technical post in the company. Why does a multi-million founder want to get their hands dirty? Because they understand that Product Development and the Technical Aspect of it is the heart of a Software House. A Technical Lead is like the Colonel (highest-ranking officer on the battlefield), while the Product Manager is the General (officer who gave orders to the Colonel) and the higher management would be the Secretary of Defense and the President.

Another role missing in the picture is a Quality Assurance (QA) Personnel. Why not ask the programmer to test their own product? Even a novice programmer would that would be practically ineffective. How could you expect product quality without a QA Personnel? Even an ISO procedure can’t guarantee good product quality. There is not point to keep emphasizing on quality improvement without the proper resources assign to tackle the issue.

There is a good book entitled “Good to Great”, analyzing the difference between a Good company and a Great Company. There is one phrase which continuously pops up in the book – “Get the Right People on the Bus, Get the Wrong People off the Bus, and Get the Right People on the Right Seat”. It is important to be able to identify the right person to employ. You can ask a Sales Manager to identify a Superb Salesperson, and he will do a great job. If you ask a Sales Manager to employ a programmer, he will end up employing another Salesperson as well. The Sales Manager does not know what quality of a programmer to look for (programmer are mostly Introvert, which is the exact opposite of a Salesperson), because he is not familiar with it. Assign the right people to recruit the right people. You might not see what others saw, but you must be able to trust others judgment. Getting the wrong people had a DOUBLE negative effect. Not only he is not productive, most probably he will be destructive to others around him. A bad sheep is enough to disrupt the morale of a flock of good sheep. Last but not least, get the right people on the right seat. Why would you want to promote a Programming Guru to do Project Proposal or Tender? He might score 10 in programming, but score 6 in preparing Project Proposal. Not only you loose a perfectly good programmer, but you got yourself an average person to perform Project Proposal and Tender as well. Why not promote them a Technical Leadership position? We are a software house, we don’t have to promote everyone to manager as part of career progression. For example, the Government started to realize the true productivity of a teacher lies in teaching. Thus, the post of Super Teacher is created, rather than forcing them to become Administrative Staff. Let people do what they are good at.

Continuous Effort is a big issue in COMPANY X. Product X 5 was launched almost 18 months ago, after which none of the core developers are assigned the tasks to continuously improve the product. Until today, Product X 5 had virtually stayed stagnant for 18 months. When the market had moved forward, a stagnant product shall fall backwards. If ISO is not a destination but a journey, so is Product Development. We should have assigned a core Product Team to continuously development the product, while creating another Support Team to perform deployment and product support. How could a software house have a stagnant product for the period of 18 months and expect to remain competitive? Or are we having the mentality of System Integrator? If you don’t have a persistent Product Team, you will never end up with a competitive product. You would only come up with a One-Time product which you try to squeeze every ounce of profit from it until there is nothing left. If you keep milking a cow without feeding it nutritious food continuously, you will end up with either a “non-productive” cow or a dead cow. To be able to harvest the crops throughout the year, you have to plant the seed for the first time and every other time after you harvest them. Not to mentioned a continuous irrigation system. Great works are performed, not by strength, but by perseverance.

Diversification can be an evil in disguise. World-renowned Investment Guru Warren Buffet (of Berkshire Hathaway) once said, “Don’t diversify; Concentrate on a few core holdings and watch them carefully”, while the Wall Street mantra is “diversify, diversify, diversify”. I would choose to put my money on the World’s Second Richest Man. Most successful Software Company started only with a single product and goes all the way to nurture and grow it. Microsoft started with DOS followed by Windows; Oracle started with only Oracle Database. With limited resources, we can’t really afford to diversify too much. With fewer core products, we would be able to concentrate and grow the product to a more superior one, rather than a bunch of average products. Although diversification would give us a bigger playing field, but wouldn’t it be better to become the biggest player in a smaller playing fields (get a big pie) rather than a smaller player in a big market (get the crumbs)? We can then choose to diversify when we have more resources and a stronger footprint in our market segment.

There is an old Chinese saying, “If you want to do a good job, you must equipped yourself with the right tools”. The basic tool a programmer need is a good PC. Is it worth saving RM 2000 of one time cost and sacrifice the productivity of a programmer, which you pay RM 2000 monthly for? With a slow PC, the programmer will spend most of his time waiting to things to load, which have a DOUBLE negative effect as well. Not only he loose time waiting for the computer, his minds also wonders off while waiting. While the processing completed, he had to bring his mind back and refocus again and again. What is the reasoning behind giving an Administrative Person a Pentium 4 machine while asking a programmer to use a 4 years old PC? Is there more value in giving the Administrative Staff a faster PC? By not paying the RM 2000 for the programmer’s PC, we actually loose more than 10 fold the amount due to lost of productivity and morale. Rather than justifying why we should purchase new PCs, probably we should justify why we shouldn’t buy.

PC is just the very basic. Another aspect is Software Development Tool and Software Component. With the right Software Development Tool in place, it would actually increase the productivity of the programmer at least by two folds. Would you rather paying a couple thousands Ringgit to buy the right tool or paying the programmer double his salary and double the time to get the task completed? Productivity is one aspect of it; a good Software Development Tool also helps to increase product quality. The main purpose of a Software Component is to add more advance feature into our current product without needing to spent too much time and resources on R&D. COMPANY X encourage us to look for free solution to avoid incurring extra cost, but we actually loose more by loosing product features and producing a lesser quality product. Good things sometimes come cheap; but it doesn’t come free (with the exceptions of a handful of reputable Open Source product). Without proper hardware and software of the programmer (which is the very basic of things), we can’t really be serious in considering ourselves a strong Software House?

The above is just a few things I can think on top of my head, there are so much more we could do to move ourselves from the Good position to Great. COMPANY X had a very innovative improvement on the Sales aspect of the company, by expanding the Sales & Marketing Division and creation of Client Service Division. It is a great move to boost the much-needed Sales of the company. Maybe is the right time to make the same move for the Product Development element of the company. To be a Software House, we need a Strong Product Team to create the much-needed Core Product to set a strong footprint in the market. We can’t understand everything; we just have to know the guy who understands the thing, which we don’t. COMPANY X need to catch the wind of change to become a reputable Software House, unless she is satisfied with her current position. From Good to Great, there are only a few distinctive factors, which separate them. COMPANY X is always Good, but was never Great. Perhaps it is time to make a leap?

Programmer Symptom: Weak Documentation and Support

Below is a letter written by me to a local software house which had sold us their SDK. This company had quite a solid product, but they fall in the trap of being too development/technical centric. I have no doubt they have pretty good programmers on the team, but they suffer the downfall of Programmer Symptom: Weak Documentation and Support. Usually you could escape easily when you are selling a end user product, but sadly they sell SDK (Development Platform). I hope this would enlighten some of you out there who are trying to make a living by making commercial SDK.

---

We have been using Product X for about 1 month plus, and we found great difficulty in trying to master it mainly due to the lack of API documentation and sample codes.
The following is some of our suggestion to improve the usability of Product X Development tool.

1. Product X Developer Portal
Since Product X is not an Open Source project, it lacks the developer community's support. Plus, we could not find help/reference anyplace else besides Company X. If you don't provide enough support and resources, we are basically trapped and helpless. Thus we would suggest you create a developer-centric portal which focus on Product X's latest release/patch/tools, programming article/resource and alike. Spare us the sales material. At lease we have a centralised site for all latest Product X material, rather than me have to keep the bit and pieces of update from email to my local harddrives. I might even suspect I don't have the latest full kit.

2. Forum
The current forum should be a compliment to the Product X Developer Portal. Since there is insufficient documentation and sample code, the Forum would be our only source of knowledge (thus we depend heavily on it). But, we would appreciate fast response regarding our posting, as it is quite frustrating if we did receive any useful response within a timely matter (please remember that we depend on it a lot at this moment, it is our only hope). It would be nice to have a response time of 24 hours, as anything more than that prolong our agony and disrupt our progress. In fact, a responsible personal should be appointed to monitor the forum in a daily manner (he will be responsible to remind the developer to reply to the forum, and make sure all queries are responded in a timely manner - leave no stone unturned).

3. Documentation
I have to be frank about this: Product X documentation is weak. The Javadoc lack of useful description, especially using some of the more obscure and advance method. I am totally lost and have absolutely no idea how to use those API, and have to keep guessing and experimenting (a big setback in terms of productivity). I understand that programmer naturally don't like to do documentation, but this situation had got to improve (you are selling a development platform with APIs, and we need to understand them in order to use them). What I would suggest is to hire a newbie programmer with good documentation skill to learn how to use Product X, thus enhance on the documentation while he is learning how to use it (for every questions asked by him to the Product X Team is the questions faced by other developers, document those down and share with the rest). Basically, you need a dedicated person to do documentation for Product X (a superb technology serves no purpose if no one could master it except its original developer). At the same time, he could create more sample code using Product X to be shared out with the Product X Community as well. Probably you could consider releasing a book on how to use Product X (try to get someone with experience writing technical book or tutorial, else it might become disasterous), step by step tutorial style. That would save on your training and support cost for the long term. Successful open-source project such as Strusts, Spring and Hibernate had good documentation (not perfect), numerous tutorials from various author, active forum and centrailised resources.

4. Sample Code
Sample code is the flesh and blood of a SDK, probably more important than the documentation itself. I can live with lousy documentation, but I certainly cannot live without sample codes. Product X does provide some very basic sample codes, but these sample codes lack real-life practicality and demonstration of advance feature. I know of Company X created many Product X DEMOs for various projects, why not release these samples (with source code of course) in the Product X Developer Portal for the community. At lease these sample codes are more advance and "real-life" compared to those which come with the SDK. What do I mean by real-life? For example, how could I use Product XDB to extract data from a joint table (mix with SUM, GROUP BY, CASE) and display it using NETable (want to show total as well at the last row), and allow user to edit it and update back to the database. Frankly, I haven't figure out how to complete the entire process. At first I bump into problems using Product XDB for joint table (Product XDB documentation is much weaker than Product X, and samples are either incomplete or almost inexistance), until I totally give up on it and use Hibernate instead (the engine is more superior, with great support, but its architecture don't quite fit into Product X's client server environment - much to be researched on). Now, I am using Hibernate but facing some undocumented problem using editable NETable and waiting response from the forum. We need useful real-life application sample using Product X, not some newbie sample, which don't quite serve any purpose. Besides releasing the DEMO samples, you could have a dedicated person writing documentation and creating real-life application samples for the community (based on feedback from the community). Having done this not only increase the usability of Product X, but it reduce the support strain on your development teams with all these Product X queries bombarding their email and forum (which might frustrate them and disrupt their daily work and productivity as well).


If Product X is ever to be a widely used SDK/Product, you would probably need to put more effort and investment in helping the developers to master your product. I know documentation is not everyone's cup of tea, but someone have to do the dirty work (and make sure he is an expert of dirty work). If I ever found an average Rich Client product (even though Product X is much superior) with good support (documentation, code samples, huge user base), I would probably abandoned Product X (just like the case for Product XDB). I think I kind of know Product XDB is more suited for Product X's Architecture compared to Hibernate, but I really don't have a choice (because I don't know how to use the more complex feature of Product XDB). Currently I think the only way for me to increase productivity is to rent a cubicle in Company X so that I can have an expert next to me whenever I faced a problem (I might just suggest that if I am desperate enough).

I sincerely appeal to you to consider my recommendations and make Product X a more developer friendly product. Your attention and swift action is greatly appreciated.

I think Product X is quite a good product, it is ashame to let it down due to poor support.