B is for bureaucracy – that hated of all things! The two biggest producers of bureaucratic requirements are governments and union (as in Union Contracts). On the plus side, it often compels companies to buy software. Healthcare is one of the biggest ones but it require domain expertise often. There are many more, for example staffing levels at nursing home [paper]. You look at the requirements and start building a sellable application around that.
The key to this is to be first or early to market with compliance to the regulations. There are two approaches –
- producing a replacement system for what they are using. Your key selling feature is compliance, but you should be competitive on features (see prior post)
- produce an add-on. This means researching what people are using and figuring out how to get the data out/in. For example, many businesses use Quick Books.
Many firms are customer request driven – they will not look at reporting requirements until the customers request it. The customer will not request it until they are reminded by government that they must provide the information. They are reactive. You get the advantage by being proactive. Your sales force can educate the customer and then sell the package.
The add-in approach is low investment with the added advantage that your customer may well ask for additional addins that the product provider have not produced. At some point the combination of extra features and familiarity of the competitor product may enable you to offer a complete replacement to the same customers…
You need to learn about how regulations are issued – usually they are circulated in draft form. Look for the newest/latest requirements.
If you start at a state, city or county level you may even be successful in providing them software on a fee-per-transaction basis (paid by the customer) for capturing the regulation data on a web site. With budget crunches, it would be tempting…
“B” projects are not exciting but they tend to be an overlooked area.