Hi, I’m Sumit. I’m based in San Francisco and am the CEO and CTO of Tivix, the Business Unit of Kellton Tech. We operated as an independent company for 10 years, starting in 2008, and were acquired by Kellton in 2018. We have around 95 employees who are based all over the globe, primarily in North America and Europe. We build innovative digital products for a variety of different companies all the way from early-stage startups and NGOs to Fortune 500 companies.

Sumit, you mentioned that you’ve been building digital products with Tivix since 2008. What are the most common mistakes you see founders make when developing their MVP?

Some of the most common mistakes are around scope – the questions of: what are we building? In software the easy part is writing code, the hard part is what to write code for. That’s a general struggle in software engineering, but typically founders struggle with that the most. Not only because they’re building something new, but also because they are trying to innovate and carve a niche for themselves.

There are often theoretical discussions around what an MVP actually is. This can become a drag in the process. Many founders feel it needs to be cheap or unplanned because it’s an MVP. That ‘quick and dirty’ approach can work for some, but everyone has their own journey and you have to pick and choose what your MVP or initial offering will look like. Ultimately, founders have to go with their gut feel.

You want your MVP to be testing the highest-risk assumptions that you’ve made about your business and future revenue model. The easy bits will fall into place, it’s the high-risk assumptions that need to be tested as early as possible. Founders who don’t do that can be setting themselves up for failure.

What advice would you give founders struggling to define their product scope?

Talk to your users. Talk to your customers. Test your risky assumptions. Build small as much as possible and don’t get hung up on the longtail features because you’ll have years, if not decades to get to them! Build narrow, but build to delight the customer. Don’t try to cover too much surface area from the get-go.

A lot of founders aren’t from technical backgrounds. What should they be wary of when making their first technical hire?

The first step is to understand why you are making that hire. Why do you need that CTO? In many cases non-technical founders want to hire a CTO because their investors have told them to, or they’ve read online that they can’t raise money without having a technical person on-board. All of which may be true, but as you go to raise a seed round, you may not want or even need a CTO. If you do – you have to balance the management component with their individual contributor aspect that you need as well. If you do make that hire, maybe give them a Technical Architect title or Team Lead where they have the option of one day becoming the CTO, but you’re not making that hard and fast decision right away. In the early days you really need someone who is hands-on, not someone who’s purely management.

That’s great advice. So for founders who are weighing up hiring internally vs. outsourcing for technical roles, what are the pros and cons of each?

Budget is a big driver in the early stages. Founders don’t want to have a full-time team of designers, product managers, engineers, and architects on their payroll until they’ve achieved product-market fit. Or have raised enough funds.

Working with outside firms enables you to go from 0 to 60 really fast. Establishing an internal team takes more time…and time is the only thing you can’t buy more of! If you can find a good external partner who is aligned with you and there is good product focus, magic can happen. You don’t always want to continue with them long-term, but in some cases, these external firms can own parts of the product, even while you continue to grow your internal team. You can build a scrum team model with a mix of internal and external staff.

A lot of functions like design, QA, and product management aren’t needed in a full-time capacity. Working with an external partner can give you flexible access to these roles, so you can get the benefits without having to pay somebody full-time. Good external teams will have worked together for a long time across different digital products. They can bring this past knowledge from past engagements and industry-specific work to the table. That can add a ton of value.

But how do you go about choosing the right external digital partner? Is trusting a third party to build your product not a big risk?

When picking an external partner, you want to find one that hasn’t spread themselves too thin. Whether that’s across technologies or verticals. The term agency or ‘consulting firm’ can mean a lot of different things. If you’re building a new digital product offering, you probably don’t want a marketing agency or a pure design agency. You want someone who is specifically focused on product development, and can be a good partner for you on your journey.

OK so avoid an agency that claims they can do everything. What should I be looking for?

Finding partners with a good balance can be harder than you think. Look for product-focus, strong capabilities in product, design, and engineering. And how these areas fit together in a harmonious way.

Purely on the technical side of things, look for teams focused on a few technologies, not dozens of them. Technologies come and go, but finding engineering teams who are really good with certain frameworks, languages, or development approaches can be tricky. If you can find those teams you can focus on building, not what languages or framework to use. Those choices can take up a bunch of time in the early stages of a company. Eventually, a lot of those choices are reconsidered a few years down the line anyway, so you always want to lean towards action over extensive analysis.

Since you launched Tivix more than a decade ago you must have seen lots of change in digital transformation trends. What are some of your biggest insights over the years?

A lot of things get lumped into ‘Digital Transformation’ when really you can see them as two distinct paths.

One is digitization – where you’re taking an existing process and digitizing it.

The other bucket is true innovation, where you’re not just lifting and shifting a process, you’re actually using digital tools in an innovative way.

In terms of building software products in both scenarios, in many ways, things have gotten easier on the software engineering side. But at the same time, things have gotten more complex. Take DevOps and Cloud as an example, it’s been around for 15 or so years but the number of iterations can make things look pretty complex.

10 years ago you could spin up a virtual machine and launch a web app. Today there’s a whole world of services around this; Terraform, Docker, Serverless…the list goes on. Even building a simple web application can seem pretty complex because there’s such a large ecosystem out there. But on the other side of the coin, it’s become very structured. Large organizations are reaping the benefits of this because they can take existing complex architectures and map them to future systems that are Agile, DevOps, and Cloud-focused.

Today, there are way more moving parts in a web app, but it’s much easier to scale and far cheaper to build than ever before. Overall it’s a huge net positive for digital transformation and enabling it in large organizations.

What about during this last year? Have you noticed that sectors using legacy systems are accelerating their move to the Cloud due to COVID-19 and other external factors?

Absolutely, the pandemic has been one of them. The other big external force is the younger generation entering the workforce. Their expectations around what work is and what work tools should be is a significant driver. We underestimate that but every couple of years we see that generation demanding more.

Some verticals are more suited to digital transformation than others, such as Fintech and legal tech. What will it take for verticals that are struggling with legacy software (logistics, construction, transportation) to start advancing to the cloud?

Innovation needs to go hand-in-hand with business, marketing, legal, compliance, and other areas. It’s not purely a digital function to innovate. You have to innovate on all those functions. Digital can be the ‘aha moment’ and present a way to go to market. Customers care about the experience and how they interface with brands. But behind the scenes, all of those other functions can’t be left behind.

I think it is a ‘do or die’ for many of these industries. We’ve seen companies like Uber or Airbnb that have transformed industries. There’s absolutely no reason why logistics, construction, or other industries will be left behind, and I expect huge transformations to come in those sectors. One issue is these industries can have higher barriers to entry, and rightfully so – we aren’t yet able to leave the diagnosis of serious diseases or the construction of buildings safely in the hands of AI. But there is a long tail of things that can be done in an automated fashion that we’ll see emerging over time.

And if you could give one word of advice to founders about building their first software product, what would it be?

I’ll give you three words – validate, plan and execute. Those are the three key things you need to focus on. Everything you do needs to fall into one of these buckets.

Finally, a big question, what’s the next in the evolution of software development?

One hundred percent open-source frameworks and stacks running in the cloud. Both of these leveraging internal and external microservices. That’s my summary of what the next evolution is. Now, some people might say that these have existed for a long time. All of us have been exposed to either open source or cloud microservices, but all of these coming together in a very cohesive way? I think that’s going to drive the next evolution of software development.

Key takeaways:

• Your first technical hire needs to be happy in a hands-on capacity. Consider looking for a lead architect that you can promote later, rather than a management-focused CTO.
• Don’t spread yourself too thin too early on. Focus on a narrow set of features that add real value for your customers and expand gradually from there.
• Avoid external partners who lack a specific focus. When building your product, look for agencies that focus exclusively on product design and engineering.