Tim Sae Koo is the founder and CEO of SaaS company TINT. He’s a 27-year-old Los Angeles native residing in San Francisco who dreamed to become the first Asian American POTUS to solve impactful problems with a purpose. Tim studied entrepreneurship at University of Southern California and graduated early to start a company and fulfil his original life mission.
His company, TINT, helps brands humanize their marketing to build trust and increase conversions along every step of the customer journey by leveraging authentic customer content. TINT is a 5-year-old profitable, bootstrapped company headquartered in San Francisco with 30 employees and has over 5,000 brands in 172 countries as customers.
I spoke to Tim about his journey as a SaaS product entrepreneur based on his unique team setup, the challenges they faced and how they overcome them with specific tips and strategies to learn from. Below is an excerpt from the interview.
The Setup
When we first started, I had two technical co-founders (one frontend, one backend) on my team eager to build. But they were also very skeptical, so it required me to always validate before we spent expensive engineering resource and time building out.
Our process would entail defining a hypothesis of customer problem, CEO (me) would email out a few people in the industry to validate with questions, and engineers would build out bare minimum. I would then craft a pitch that catered to a potential customer and try to get as close to a contract commitment.
Lots have evolved in the last 5 years. Now we have 1 Product Manager, 1 Designer, 1 CTO, and 7 engineers. Our product manager will take feature requests coming from customers and sales / CS team members. Then categorize them into problem statements.
Once done, we will spec out wireframes and then share with a few select customers who have been with us for 3+ years and gauge their response on it actually solving their problems.
Once validated, PM will create user stories and then pass off to engineers to create within 2 week sprints. Once delivered and shipped to production, our customer success team will go pitch to existing clients and sales team will pitch to all increase contract values.
Customer feedback and increased contract value data will be passed back to product team to see what could be done better.
The Challenge
In the early stages it was about learning how much validation is enough validation.
A current challenge that proved to be a major roadblock in the company’s growth was how do we know if a rolled out feature was actually a success.
Pivotal Moment
Early Stage: We had many feature requests come in, especially from sales people. To prioritize and know which features were worth building, we would validate with a combination of future customers, current customers, and our own analysis.
For future customers, we would see if any new deals would be committed if we built certain features. For current customers, we would compile curated feature requests into a survey and get their input.
For our own analysis, we would look at both sets of data on top of market trends/changes. Not easy and not the only way.
Current Stage: When we roll out features, it's easy to hear a lot of celebration from team. But rolling out a feature is just half the battle.
We didn't have the discipline to see the success of those new features pushed to production. So now we ensure we look at usage data a month after a new feature is rolled out.
If not successful, we dissect why and see if it's valuable from a sales/CS perspective. Sometimes it may just require some extra marketing or UI changes, but sometimes it's because the feature is not a priority, which means we were flawed in our validation process.
End Result
It disciplines the whole team to understand more features does NOT mean a better product. It focused the team to approach all potential solutions from a "What is the problem" perspective.
Questions You Should Be Asking To Arrive At The Solution
Early Stage: What is the most pressing problem a customer has that we do not solve within our product? Would they pay more for this? If not, is it just nice to have?
Current Stage: Are we just clogging more features into our product or is this truly a value add? Is this feature something universal and helpful for everyone? If not, can we only include it in certain areas of the product strategically?
A Word Of Advice To SaaS Founders
Whenever a client wants a new feature, take a step back and understand what the true problem is. I always say, start with the problem because there are hundreds of ways to solve it. Clients will typically tell you what solution they want, but that just pegs you into a path that may not be helpful for other clients.