Looks like Som and his team finally heard Developers and .NET 3.0 will ship on XP with Avalon and Indigo support. Linux Desktops must be doing really well for MS seems to feel the pressure to ship Longhorn without WinFS.

This is a good decision for .NET developers as it gives them a wider market for Avalon and Indigo. Now that this decision is made, they can work on the next one.

Charles Petzold's Programming Windows book, First Edition helped me to write the first Circuit Schematic Editor for Windows 3.0 as my college project. This interview with Charles brought back a lot of memories.

I am happy not to be the only one who used the 4.77Mhz PC or ran Windows 2.03 using only two floppy drives.  

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.

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.

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.

Avik Sengupta has a good introductory article to IKVM, which can be best described as a Java Virtual Machine for the .NET CLR. So if you are creating a .NET application, but want to use that cool new Java library that doesn't yet have a .NET counterpart, here's a solution for you. Conversely, if you are a Java developer who wants to call a .NET library from Java, IKVM is what you need.

This should be very useful for interoperability between the two platforms but I doubt that anyone will use the Java language to write .NET programs or if it will bring the two communities together.

The Java world has portal standards called WSRP and portlets. Major Java portals seem to support it. It allows you to write a portlet using web services and defines standards for local portal component behavior. It's high time the .NET world adopts some standards in the portal market segment.

For example, if I want to write a component to a .NET portal, I need to choose if I am going to support Sharepoint, Dotnetnuke, Rainbow, etc. I cannot write a portlet that works in multiple .NET portals. This hurts the small ISVs that make money writing portal components as they have to choose which portal to support. It also hurts portal administrators as it limits their choices.

ASP.NET 2.0 supports web parts which could be used as a basis for .NET portlets but the portal vendors work together to build a standard that works. If you are a portal administrator or portal component vendor then you should start pushing your vendors to work together to build a common portlet standard for ASP.NET.

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.

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.

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.