In the last year, Tanda has evolved from being a single-product company to launching multiple new products that all work together seamlessly.
Reflecting on this journey, it’s interesting to see how their product strategy has transformed over the past decade, moving from having no product at all to becoming a market leader. Here's a look at how their approach has changed and what they've learned along the way.
Stage 0: The roadmap begins as just an idea
Every product, project, or company starts at this phase: nothing built, just an idea. At this stage, the goal is to develop enough of the idea to present it to potential users or buyers and assess their reactions. In startup lingo, this is known as creating an MVP (Minimum Viable Product).
Planning during this phase is crucial but looks very different from later stages. Experienced planners from mature companies might find this phase challenging because it involves writing brief, two-sentence summaries of what needs to be built. For example:
- A project management tool accessible through any web browser;
- Integrates with various cloud storage platforms, enabling seamless file sharing and collaboration.
Some suggest starting with market research by interviewing potential buyers to tailor the product to their needs. However, this advice is often given but rarely followed. If the idea can’t be explained in two sentences, it might not be ready for a business venture.
For those who insist on customer research, having a polished pitch is essential. When aspiring founders request "customer development interviews to identify potential pain points," it often feels like a time-waster.
Stage 1: It’s crystal clear what to build next
After building the initial product and getting some users (hopefully paying ones), it often becomes clear what to build next because the product lacks many features that customers expect. This phase is crucial for achieving product-market fit.
For Tanda, this involved features like award interpretation, rosters, early versions of timesheets and leave, and payroll exports. If you're not familiar with workforce management, you might not recognize all these features. To put it in perspective, they're as essential as building GitHub without an online code browser.
These were obvious next steps because:
- Customers assumed the functionality was already there, making it an apparent requirement;
- There was no good reason for the feature not to be included, making it an implicit necessity.
During this phase, product planning is straightforward. Pick an obvious feature, build the simplest version of it, and repeat. Avoid prioritizing too much; if it’s not obvious what needs to be built, it shouldn’t be built at this stage. Build what customers have recently asked for, and keep iterating.
Seasoned product managers might caution against this approach, warning that it could lead to a product with random, disparate features that don't work well together. They have a point, but during this phase, the priority is building a variety of features to understand the market better. Accept that some features might not be perfect and that some customers might not be ideal. Use this information to identify the ideal customer base and refine the product gradually.
While prioritization is less important, scoping is critical. It's easy to get carried away with creating sophisticated versions of obvious needs, either by adding too many niche features or over-polishing. The saying, "if you’re not embarrassed by your v1, you shipped too late," applies here. The first version of each feature should be basic and cover only what 100% of customers will use in the same way. Additional functionalities can be added later.
During this phase, there will be many requests for non-essential features. For instance, Tanda didn't have a mobile app for the first four years, despite frequent requests. Instead, they used a mobile website and relied on email and SMS for important communications. This decision wasn't due to a fundamental opposition to native apps but was based on prioritizing more critical features with their small team.
Eventually, Tanda did build a mobile app, but it came after addressing more pressing needs.
Stage 2: It's hard to know what to build next
Once all the obvious features are built, prioritizing the next steps becomes a real challenge. The team finds itself swamped with feature requests, bug reports, suggestions, complaints about technical debt, and a million other inputs. While none of these seem like bad ideas, none of them scream "must-have" either.
At this stage, actual prioritization is required. The transition can be tough — moving from building whatever felt like a good idea to having to create processes to avoid building the wrong thing.
The pitfalls of prioritization
- Giving in to big customers
Big customers often ask for features tailored specifically for them, which can be tempting to build. Many experts advise against letting one customer dictate the roadmap, and for a good reason. Initially, it might seem manageable, but eventually, it’s difficult to build something universally useful. Tanda learned this the hard way, building features that worked well for specific large customers but were too confusing for others.
The takeaway: Don’t build features just for one customer. It's hard to resist, but it ensures broader applicability.
- Prioritizing by revenue (MRR)
A common but flawed method of prioritization is sorting feature requests by the revenue associated with the requesting customers. This approach assumes that building certain features will attract or retain high-revenue customers. However, decisions made purely on this basis often don't lead to winning new customers or keeping current ones. It's rare for a single feature to be the sole reason for a customer's decision to buy or leave.
This method sounds logical but tends to create a mess in practice. Sales teams can be persuasive, pushing for features that might not align with broader product goals. Striking a balance between listening to sales and sticking to a strategic product vision is crucial.
Frustrated by revenue-driven development, some teams might decide to focus solely on big, innovative projects. This is appealing — developers love working on major projects, and everyone enjoys new, exciting features. However, assuming there’s an endless supply of game-changing ideas within the company is unrealistic. Good products come from fostering the right conditions for innovation, not from forcing teams to constantly churn out big projects.
Forced innovation often leads to complex features with fancy names but little real impact on customers' lives or the company's fortunes.
Like many product teams, Tanda invested in analytics tools like Amplitude to drive data-informed decisions. However, while these tools are powerful, they often only confirm what is already known. Insights like "lots of people log in every day" or "user profiles are frequently used" don't offer groundbreaking revelations.
The same applies to recording tools like FullStory. They are useful for identifying bugs but rarely provide deep, untapped product insights. Ultimately, these tools are poor substitutes for direct customer conversations.
Lessons learned
The key takeaway from these experiences is the importance of balancing various inputs and pressures without losing sight of the broader product vision. Tanda's journey through these phases highlights the challenges and complexities of SaaS product strategy, emphasizing the need for a nuanced approach to prioritization and innovation.
Stage 3: Getting aligned
At this stage, the name of the game is alignment. The biggest impact from building new features comes when the whole company is in sync. It’s a big shift from the early days when a feature idea over breakfast could be shipped by dinner.
Take the example of when Tanda improved how it handled different kinds of lunch breaks in shifts. They sent prospects a Kit Kat in the mail along with a flyer about the new features. This quirky marketing move worked wonders, drawing attention and sparking conversations. More importantly, it got everyone at the company on the same page. From designing features to packing Kit Kats, everyone knew what was happening and could explain the new features to customers.
Two patterns are crucial:
- Align product thinking with how other teams prioritize work;
- Sync product releases with how customers will deploy new features.
For Tanda, this meant working on a quarterly cycle. Every three months, the company refreshes its OKRs (Objectives and Key Results). About a month before that, they pick the product theme for the next quarter. This approach ensures every team knows what’s coming, where to expect improvements, and how to align their work.
This method has been working well, but they acknowledge that there will likely be future lessons learned from missteps.
Stage n: Adding another product
Currently, Tanda is launching new products, reflecting on their journey as these new ventures are still in the early phases. It's obvious what to build next because there's still so much missing, allowing for rapid progress, even with the understanding that some things will need to be rebuilt along the way.
Adding a second product is a bit like deciding to have kids. Most people think they'll do it eventually but wait until they're "ready." However, waiting for a sign that you’re ready means you’ll never start. Once Tanda began building a second product, it wasn't as hard as expected and proved to be very rewarding. Customers who buy more products tend to be happier, which has energized the whole team.
Would it have been better to start earlier? Probably. It would have been tougher and more chaotic, but there’s a lot of sunk cost fallacy in thinking otherwise.
Should you add a second product?
If you’re transitioning from Phase 1 to Phase 2, consider adding a second product. Even if you decide against it, it’s worth weighing the option.
If I had a time machine
Looking back, here are three big tips:
- Be less afraid of new products/markets. New products or markets can seem daunting, but they energize the team and boost focus more than expected;
- Change or remove features that aren’t working. Don’t be afraid to scrap features if they’re confusing or not serving the majority of customers well;
- Build what customers say they’ll buy. It’s tempting to follow other inspirations, but the best strategy is to build what customers are asking for. Ignoring this advice leads to too many features that don’t work well together, while building for customer needs keeps the business thriving.
Conclusion
Reflecting on Tanda's journey, it’s clear that successful product strategy involves continuous learning, alignment, and being responsive to customer needs. From initial ideas to adding new products, each phase brings unique challenges and opportunities. By staying adaptable and focused on what truly matters, Tanda continues to grow and innovate, setting a strong example for others in the SaaS industry.
