Learn Fast, Outside and In: Our Approach to Experimentation

At PredictAP, we believe the best teams learn continuously—from data, feedback, and the market. That means we don’t just react to what’s happening outside our walls; we also learn from what’s happening inside them. Engineering is where this belief comes to life every day. Our structure intentionally balances focused delivery with freedom to explore, ensuring that we’re building the right things and building them the right way.

How we Structure Engineering Time

We’ve built a framework that ensures we’re always learning, improving, and delivering. Every engineer’s time is roughly broken down into three buckets:

70% – Product Priorities

The work our product team defines as most valuable for customers and the business. This is where PredictAP’s roadmap becomes real—new capabilities, performance improvements, and features that deliver measurable value to property management and accounting teams.

10% – Tech Debt and Internal Improvements

We reserve time every sprint for the things that make engineering better—refactoring difficult code, improving developer experience, cleaning up infrastructure, or automating repetitive internal tasks.

The goal: keep the system healthy so speed doesn’t come at the cost of stability.

20% – Experimentation

This is where the magic happens. Every engineer gets dedicated time to explore bold ideas—things that could improve how we work, how we serve customers, or how we operate as a company.

The Power of 20% Time

20% time is our engine for innovation. It’s how we learn fast, outside and in—pushing boundaries with new ideas, tools, and approaches.

Sometimes the experiments succeed. Sometimes they fail. Both are wins. Because every time we fail, we’ve learned something we won’t waste time on again.

Engineers use this time to:

• Tinker with new frameworks or AI tools that could unlock efficiencies.
  
  
• Prototype new ways to extract value from data.
  
  
• Automate internal workflows or infrastructure tasks.
  
  
• Test hypotheses that might one day evolve into production features.

The only rule: every experiment must align with our company OKRs.
That ensures curiosity is always pointed toward customer and business impact—not just novelty for its own sake.

Turning Curiosity into Practice

To make experimentation real and repeatable, we’ve built structure around it.

Every two weeks, we hold a dedicated 20% Time Demo meeting where engineers:

1. Demo projects – share what they’ve built or explored.
   
   
2. Discuss results – what worked, what didn’t, and what surprised us.
   
   
3. Decide next steps – which experiments move forward, stay in 20% time, or get archived.

Where the Real Value Returns

After every demo, we evaluate what happens next. Not every project becomes a feature—but every project becomes a learning.

Next steps typically fall into one of four categories:

1. Product Priority – The experiment shows strong potential to push an OKR hard. Product picks it up for roadmap consideration.
2. Continued Experimentation – Results are promising but inconclusive; it stays in 20% time for more exploration.
3. Tech Debt or Internal Efficiency – The idea improves developer experience or system health and becomes part of our internal backlog.
4. Ditch It – We’ve learned that it’s not valuable—and that’s valuable learning in itself.

This structure ensures we never lose momentum. Every outcome—success, failure, or in-between—moves us forward.

A Real Example: Automating Infrastructure Operations

One of our biggest 20% time wins came from a project aimed at reducing engineering overhead through automation.

A few engineers noticed that routine operational tasks—like Kubernetes upgrades or even executing disaster recovery (DR) failovers—required too much manual coordination.

During their 20% time, they built internal tooling to automate these infrastructure and devex tasks.

The results were immediate:

• Faster upgrades with less risk
  
  
• Repeatable, documented failover processes that reduced human error
  
  
• A measurable reduction in engineering time spent on maintenance

That experiment transitioned from a curiosity to a cornerstone of our reliability strategy—born out of curiosity, refined through iteration, and scaled through production.

Why This Matters

PredictAP doesn’t innovate by accident. We innovate by design.

By deliberately setting aside time to explore, fail, and learn, we’re constantly building the muscle of experimentation—and embedding learning into the way we work.

Because learning fast, outside and in, isn’t just a belief. It’s how we build a better company.