Skip to main content

How we built it and why

business
(Image credit: Image Credit: Rawpixel / Pixabay)

The question of how and when to go from idea to execution to customer adoption as a startup is fraught with pivotal decisions. There will always be unsettling turns in the road. While there are many ingredients to success and no sure formula, despite the best-laid plans, a primary consideration for a software company is the technology platform. You need to build a product that customers love, which IT people love if you’re selling to the enterprise, and which is not only built to last but can adapt and flex with the marketplace and technological shifts.

Here’s how we approached the technology platform decisions in the early days of our company, which might provide insights to other founders walking down a similar path today. My co-founders and I have previous experience building companies together. Our background is in building and running scale-out architectures. These learnings helped us move faster in launching our company. I hope they help you too.

Nailing the problem and market. Finding an idea that you’re passionate about is much less important than finding the idea which solves a clear problem; for us, this was the exploding growth of unstructured data in the enterprise. Of equal importance, we knew that this problem was not only going to get more and more thorny with widespread implications on cost and performance for IT organizations, but it was a large market. There’d be plenty of space for us to make a difference and carve out a viable value prop and significant customer base.

Lesson #1: Find a customer problem that truly matters and ensure that it has a customer base to support year-over-year growth and ROI. 

Look for the holes. It’s vital to get feedback as you build a prototype so that you can avoid a costly mistake when you launch the first product. Fortunately, we knew a lot of CIOs and IT leaders in Silicon Valley who were happy to give us their opinion on the product. (These days it matters less if you’re in Silicon Valley, as long as you find the right audience to review your work in progress). Our colleagues were happy to share what they did not like about the product, which ultimately led us to create one of our key differentiators.  We redesigned the product accordingly, and that has made all the difference. 

Lesson #2: Take the time to seek out the gaps and barriers in your product with potential buyers and make the changes required, even if it means spending more on development and delaying your launch.

Keep it simple...and automated. Our prospective buyers had more advice: while they were excited about the analytics portion of our product – allowing them to see where they could store data to save money – that wasn’t enough. CIOs wanted a tool that could not only provide a recommended action but could make it happen. Nobody wants to buy another tool or walk through a series of painful manual steps if a product can go the last mile and execute upon the analysis. In our case, that’s often to move cold data automatically to cheaper storage based on policies the user sets. 

Lesson #3: Consider how your product can complete a lifecycle process for the customer, eliminating complexity and cementing opportunities for future value and innovation. 

Design for the right infrastructure. In our market, this meant hybrid cloud or hybrid IT, as some call it. Enterprises want flexibility these days to host systems on-premises, in a private cloud and/or in multiple public clouds. It was imperative that our software could play anywhere that the IT director wanted to be with an open and flexible architecture that could adapt to future technology shifts.

Lesson #4: Understand the broader technology platforms and strategies which your product supports and depends upon, to help ensure a long-term market fit. 

Consider the different needs of your core users. Many software products have more than one type of user – although certain segments may have more pull than others in terms of product adoption. For instance, we need to ensure that the end-users can easily get to their data whenever it is needed without disruption. They shouldn’t need to worry about where the data is stored or have to hunt it down because it’s changed locations. Meanwhile, people using our product – storage and IT managers – traditionally have a lot of mundane and repetitive tasks. Eliminating this toil so they can work on more interesting projects – building new systems or creating new value for the business – is the goal. Finally, consider that a large enterprise customer may have a different use case: such as being able to customize or integrate your product and create their own UI. 

Lesson #5: Design your product to address the needs of each core user group and solve what may be different pain points. 

In every decision that you make early on when designing your product and establishing a go-to-market strategy, there are trade-offs. Collecting comprehensive feedback early on from different stakeholders can result in a product that is more valuable and accepted by customers, but it may require spending more time and money on development to get it right. You may have greater risk if you create a product that is built on open standards and avoids lock-in, thereby making it easier for the customer to switch. Yet by building a product that has been vetted thoroughly by potential customers, meets and (hopefully exceeds) user needs without creating unnecessary barriers, and is built to last vis-à-vis current and projected technology trends, you’ll have a far greater chance of long-term financial and marketplace success. 

Kumar Goswami, CEO and co-founder, Komprise

Kumar K. Goswami is co-founder and CEO of Komprise, the leader in analytics-driven data management as a service.