Business

My Idea is worth more than yours OR My secret is bigger than yours

ashvil_d@yahoo.com — Tue, 20 Jun 2006 16:35:00 GMT

One of the hard lessons of my startup experience was that ideas are worth very little, It’s how you implement the idea that matters. Execution.

When I see founders hide what they are doing, I smile and think – Been there, done that.

But if the idea is not important, what’s are these folks trying to hide. If the founders are smart enough, they would be talking to everyone about their idea but talking to only a select few on how they are going to implement their idea. How you uniquely execute on the idea is what you need to protect and patent if possible. This is your secret sauce and will be what investors will pay for.

Take Jack for instance - Jack decides to go after Steve Jobs and his iPod and create the ultimate portable Media player. He silently assumes that his mini laser projection display for his Next Gen Media Player will knock the socks of the iPod. After all who would not want to see videos on a bigger screen. He and his founder buddies decide to keep the fact that they are building a Next Gen Media player a big secret. All they tell others is - we are hot startup doing something secret.

It would be better for Jack to tell others that they are building the Next Gen Portable Media Player. Others can validate their idea and give them a reality check. Jack and his buddies are now operating on their invalidated idea that adding a mini laser projection is all that is required to build the next portable media player.

If they actually would tell folks (or even ask folks what they are looking for) in a Next Gen Portable Media player they would get the following comments …

Bigger screen for videos
More choice for videos and music
WiFi
Subscription service
Improved battery life
Cell phone integration
Faster sync for videos and music
ITunes service
Photo slideshow
Games
etc., etc,

By keeping the idea secret, they have eliminated all the useful reality checks that they would have had and instead set themselves up for a reality shock later.

The right thing for Jack to do would have been to patent the method of Adding a mini-laser projection system as a Display for Portable Media Players and then they would not have to play these secret games.

So next time someone tells you that they are working on a hot startup but cannot reveal any details – wish them best of luck and slowly back away ... :-)

Estimation and Scheduling of Work

ashvil_d@yahoo.com — Sun, 07 Nov 2004 19:56:00 GMT

One of the reasons projects spin out of control is poor estimation and scheduling of work. There have been tons of material on estimation but scheduling has not got the same coverage.

One of the common pitfalls of scheduling is mapping a project plan estimated numbers to a team member at 40 hours a week. Let’s run though this with an example, John is working on a 6 month project that is assuming that he would be working for 40 hours a week for the next six months. Besides working on this project, John has to attend a regular staff meeting, take care of some production support issues, take part in a virtual team for planning, attend some training and mentor a new employee. Also, John is planning to take three days off around Thanksgiving to spend the week with his family.

End result is that John this month can spend only 25 hours week on an average on this project but the project manager has gone ahead and budgeted at John to spend 40 hours a week. Poor scheduling like this that does not take care of the actual number of hours that a team member can commit and ignores vacation and holiday times are doom their projects to failures. If your project plan is based on inaccurate data, how on earth do you expect to ship on time.

There is a simple solution to this – Always plan with the correct numbers of hours a team member can spend and include vacation/holidays/buffer time.

Software Reuse vs. Innovation

ashvil_d@yahoo.com — Tue, 26 Oct 2004 02:29:00 GMT

One of the points raised by the NIH (Not Invented Here) folks is Reusing software artifacts does not encourage innovation.

The fallacy with the argument is that if there is already a reusable artifact, then by definition your artifact cannot be innovative. You are just reinventing the wheel and trying to claim that your wheel is better than all the others and thus innovative.

IMHO, Software Reuse allows you to focus on innovative ways to solve business problems by taking care of mundane building blocks.

Let’s take an example of Joe, an IT developer/analyst who is assigned to build reports. Joe decides to use ASP.NET and C# to write reports after understanding the requirements. Most of Joe’s time will be spent in writing queries, formatting reports and other low level activities. At some point of time, Management will start wondering why does it take so long to get a simple report and how come the report does not work in Excel. They will wonder where all the money they are spending is going.

Mary builds a reporting solution block that allows her to quickly build reports without focusing on the C# and HTML code. This allows her to work with the business teams and also suggest what reports add value and how to deliver to them on a regular basis via email. Mary can build a reporting solution block by reusing reporting solutions like SQL Server reporting services or reusing .NET components like Active Reports, etc.

By spending her time solving business problems in an innovative fashion with technology, Mary adds value to both herself and her organization. Mary shows true innovation by doing more than her expected role by working with her business teams to figure out how they can make quicker and better decisions based on the information she provides.

If Management had to cut or outsource a job, guess who would they choose.

A short marketing survey on Ashvil.net

ashvil_d@yahoo.com — Thu, 09 Sep 2004 09:09:00 GMT

If you have been reading Ashvil.Net or have subscribed to my RSS feed. Please take some time to help me understand why you read my blog by taking this survey, powered by nsurvey.org.

I plan to use this information to help me understand my audience better and fine-tune my articles, blog and presentations to my readers.

Thanks,
Ashvil

QuikChannel – Build your own News Channels

ashvil_d@yahoo.com — Thu, 02 Sep 2004 01:54:00 GMT

QuikChannel was my second product concept. It was conceived in 1997 during the IE 4.0 beta, which came up with the concept of channels using a format called CDF.

The problem I had with the Microsoft channel concept was that publishers control what you see and I wanted to transfer that control to the end user. The idea was to create aggregate channels from all the different news sources. Channels customized around my niche needs.

For example, If I was interested in Microsoft, then all the news items from different CDF sources (Cnet, MSNBC, etc. ) was presented on one page in a Microsoft channel.

The second part of the idea was to use collaborative filtering techniques to decide what news items the user would like to see. So if I am interested in unit testing, I create a Unit Testing channel that aggregates all the Unit Testing Information news items on one page like a Newspaper.

QuikChannel made it to version 1.0 but other priorities took over. CDF never took off and it was years before RSS became popular.

Fast forward to now. Nik from Speerio created a module for DNN that made me reminisce about QuikChannel.

Google News aggregates the News but not at a personal level or drill downs to create Niche topics. I cannot have a personal News page created from the News Sources I choose.

The online aggregators like Feedster, Bloglines are still are oriented around the publisher’s view, expect me to search for content or publish my own content.

Weird. I thought someone would have solved this problem by now. Give me a simple way to view Channels the way I want them, not the way the channel publisher wants them.

Software Pricing with Eric

ashvil_d@yahoo.com — Tue, 24 Aug 2004 04:45:00 GMT

Eric Sink has a good article on product pricing strategies on MSDN. It is a must read for anyone in the software business. If you are developer and don’t understand software pricing you will have no idea how commercially viable that widget you are developing is. Pricing is a complex issues and this article covers that all the main points that drive it.

One of the issues I have with the article is his example of setting a price point for a commercial version of Firebird. His argument of pricing it higher is not in line with his company’s pricing of Vault compared to VSS, Perforce, etc. Actually Perforce adopts his model but it’s pricing is out of reach for many developers.

One of the stupidest things to do is to price higher than lower. If you price lower you will lose money but gain customers and market share. You will find that customers want to spend money with you after they trust you. Take a leaf out of the Component software vendors – Sell cheap then you can charge for Enterprise support, Source Code, Subscriptions, Training, etc. Enterprise customers love to spend money with companies they trust.

The other thing I disagree with is to raise prices till the whining is just right. Whining customers don’t evangelize; they don’t act like sales people for your product. There are better ways to charge people who want to pay more and still include people who want to pay less.

Eric’s article is a good start but the best place for you to get your pricing strategy is talking to your customers.

The Problem and A Solution

ashvil_d@yahoo.com — Wed, 11 Aug 2004 00:52:00 GMT

The biggest mistake a product manager can make is not understand the difference between the problem and a solution.

For example, Jill knows that Mark’s birthday is in a few days and she would like to send Birthday wishes. She can send a greeting card, email or call Mark. All these are different solutions to the same problem – Jill needs to convey her wishes to Mark. Understanding this difference is the key to building great solutions. In this example, AT&T competes with Hallmark to win Jill's business.

Before Intuit launched Quicken, the number one way home users did accounting was with a paper and pencil. Intuit realized that they need to compete with the paper and pencil method and not other home finance software vendors. If the home user thought the paper and pencil method was better, they would never adopt Quicken. Using this knowledge, Intuit designed the product with wizards and other UI techniques that made it more effective than the paper and pencil method.

Unfortunately most product managers define competitors in a narrow solution space who have similar technology and business models. Quick, What is a competitor to Microsoft’s Frontpage? Macromedia Dreamweaver? How about portal software that allows editing via web browser. How about software that creates email newsletters. Unless you know the problem that the end user is trying to solve it pretty difficult to tell, who your competitors are.

Companies that are competitor focused and blindly replicate features because a competitive product has it on it feature matrix are run by product managers who are carrying a signboard that says – Run over me. The right way to build a product is really know the pain of the customer problem and find an innovative way to solve it.

Products that are narrowly focused die out when there is a better solution to the same problem the end user is trying to solve. Remember the dial-up BBS business, the Internet has consumed it. Technologies like DSL make dial-up modems useless. It’s no use being the number vendor in a dying category.

If you are with a company whose marketing folks can do fancy spreadsheets and graphs but cannot tell you what problem they are solving, it is time to bail out.

Capturing Tacit Knowledge

ashvil_d@yahoo.com — Mon, 09 Aug 2004 09:23:00 GMT

Peter Donker has a good article on the difference between tacit and explicit knowledge. Explicit knowledge denotes the knowledge embedded in artefacts such as documents and databases. Tacit knowledge refers to the knowledge in people’s heads.The usefulness in this distinction lies in the fact that explicit knowledge is easily duplicated and distributed while tacit knowledge is not.

My vision behind Context based communication was to capture tacit knowledge during the communication process.

The best way to explain this is to use the bug/issue tracker example. When Mark, an account manager files a bug, the bug is assigned to a developer, Jill. Any communication between Mark and Jill is either through comments in the bug tracker (inside the system in a constrained fashion) or via email/phone/IM in an free form fashion.

When Mark and Jill directly communicate outside the system, they are more productive but this information is lost even though there is context around the bug that they are discussing. Imagine now, if this information could be captured, indexed and sent back to the bug tracking system. You suddenly have information that was otherwise lost and transparently captured this during the communication process. Imagine this being done for all our business communication across differently applications.

Tacit knowledge flows out of people during the communication process and capturing transparently is a key to building great knowledge management systems. We did implement a little bit of this vision at i3Connect as this case study demonstrates.

Good Interviewing

ashvil_d@yahoo.com — Wed, 04 Aug 2004 01:41:00 GMT

It’s amazing how interviewers ask stupid questions that do more harm than good. Good interviewing is a science that we can all learn and it is the first step to building a good team.

The first step to being a good interviewer is to realize that the candidate is also interviewing you silently. The purpose of the interview is two fold – evaluate that the candidate is a good fit and sell him the job.

Most folks believe that the time to sell the candidate the job is after you decide if you want to hire them. This is a bad choice because if the candidate is not sold right from the start the chances that he/she will perform to their best potential is low. A motivated candidate who wants to get the job will try to sell themselves better than someone who has no idea what the job involves.

The best way to start and interview is to sell the company and the job position and then ask the candidate if they are interested in it. One note of caution – Be honest. Hyping up the company and the job position or hiding information is a bad idea. Once the candidate becomes an employee, they will know the truth. It is a bad idea to hire an employee under false pretences and then wonder what when wrong.

Once the candidate expresses their interest, go ahead with your interview process. Make sure that interview is tailored to the job position. But whether you are looking for a CEO, program manager or developer, there are common attributes you should be looking for like honesty, decision making process, intelligence, hardworking, teamwork, match with the current position, etc.

I focus on asking these type of questions

What interests you about the job and drill down
See what kind of research the candidate has done about our products and market
Talk in detail about their past projects and rationale behind decisions
Find out the processes and methodology they are familiar with
Talk about interaction with their teams
Talk about the other professional interests beside their job
Ask them questions in their line of expertise that make them think and come up with solutions

And here is what I don’t ask them

No puzzles, trick or hack questions
No questions on syntax where the answers can be found in the manual
No hard or nasty questions
Never appear disinterested in their answers
And no illegal questions

Let me take a minute to explain the rationale behind not asking certain questions. The interview environment is a stressful one. Hack questions like what does the complier do in this situation does not makes any sense. Atleast reword the question to ask them what would you do if you were the complier writer. What decision would you make.

Puzzles test the ability to solve a problem given a set of artificial constraints. But you don’t need to create artificial constraints when you have a set of real world constraints. Instead of a standard puzzle like dividing the Pirates Treasure, consider talking to the candidate about real world issues you are facing and ask them to solve it.

Asking syntax questions where answers are in a manual makes no sense. With information on your fingertips, the answers are always a click away. Obviously asking questions that are illegal, immoral or uncomfortable are just going to make the candidate negative about your organization.

One of the most important things is check if the candidate understands how to make decisions, how to stand by them and how to implement them. You need to find out if the candidate understands they are there to solve a problem for their customers and how to go about it. Asking the right type of questions will significantly increase your chance of finding the right talent to lead you to the path of success. Ask the wrong ones and you will wonder why good folks don't turn up for your interviews.

How To Be Creative

ashvil_d@yahoo.com — Tue, 03 Aug 2004 22:12:00 GMT

Found Hugh Macleod's post on How To Be Creative via Dare.

Found his 13 points very interesting since I have done both kind of companies. ie. Not quitting my day job and quitting it. Both have their positives and negatives. For example, when I had a Day job, the product I was developing always fell behind due to other pressures. When I led a full time venture with 30 people, there were financial pressures to meet. In both cases, sometimes you don't have the freedom to do what you really want. Like all things in life, each model has it's plus and minus points.

The ideal one would be where you could get customers to pay you in advance to build what you want :-)