Treating internal projects like startups

One of the most endemic aspects of corporate life is living with kludgy internal software and intranets. It’s just part of the life — you have expense report software, benefits management, communications tools like message boards. SharePoint and ticketing systems and access request forms. Almost all of it, for some reason or another, is garbage.

This bad software often causes stress, takes ages to onboard onto, and reduces productivity. Forget about enabling innovation. It really doesn’t have to be this way, and we could fix that by treating every internal project like a business.

Your internal project should be like a startup

You wake up one day and think “I’ve had it with this dang portal, I’m going to get my boss to let me build a new one.” Your boss, not really thinking it matters and busy with other things says “All right, John, whatever.”

So you set off to build it. Only this time, instead of taking the existing features and making them look better, and introducing some new technology like Vue that you’ve been wanting to experiment with anyway, you stop. You think to yourself “Do people really need to use this tool? Why?” You decide that you are going to treat this like a business. You want to find product/market fit. You want to be accountable to your customers, i.e. your colleagues.

This is the way every single internal project you work on should be. Take the key decision-making drivers for any good business and inform your roadmap with the outcomes:

• Who are the key users? What are their personas and how do they get their work done?
• What features are absolutely critical for an MVP?
• If this project needs to be readily available, what is your target for scale and resilience? Intranets are notorious for frequent outages, you know.
• Design a UX and do user testing. What do people respond to? It should be easy to find testers, they are your cube-mates.
• Furthering the UX discussion — will you document it? How easy is it for people to use? Will they find workarounds if they can’t navigate your tool?
• Be sure you are tracking, analyzing, and iterating on your product.

Once you’ve got a plan in place for how you are going to build this product, be sure to actually get out there and build it. Give yourself a backlog, set some ambitious goals, and start building. If you are clever you’ll iterate around issues and keep your roadmap fluid. If your product has integrations or other dependencies, be sure to account for them.

Get sponsorship from someone important

Before you go out there and boil the ocean, pitch your project (business!) idea to a major player at your company. A VP would be a good start. Someone who can sponsor you and provide cover if needed. You need to come in with not just emotions “This existing thing sucks!” but equipped with facts “This existing thing is creating 6 hours of work per week for 70 employees!” With that data, you can demonstrate meaningful savings.

Once you’ve got sponsorship, get that person on board with your ideal timing (padded, of course) and a plan of action for rolling it out. This will have the dual benefit of making you look like a real go-getter, and will provide you a framework for keeping yourself accountable. I know from experience that if I’m not accountable to anyone else I’m accountable to no one. I don’t count for much for self-discipline.

Does your product solve a real problem in the broader market? Sell it or open source it!

If you’re really ambitious, your business has the chops to do it, and it’s not going to hurt you in the market, you could sell your business. Turning internal software into externally-facing SaaS products can be a great revenue stream. You’re already using the software, why not make some dough?

Or, if your internal project solves some real world problems, and releasing it doesn’t put your business at risk, you could open-source it. This not only has great karmic good will, but attracts creative professionals. It’s basically free PR by way of good community stewardship. Even if you decide you’re not going to use the product internally, you could still open source key components of it just for the hell of it.

What to do if your project fails to take root?

For the love of god, shut it down. There’s no reason to add more kludgy crap to your corporate ecosystem. Smother it, don’t let your ego get in the way of good sense.