01

8-10 minute read ⏱

ProNovos Analytics

PRONOVOS aNALYTICS

Turning scattered financial data into something construction companies actually use.

ROLE

solo product designer (second hire) (UX / Visual Design / User Research)

timeline

Ground zero → Product-market fit (2022)

team

ceo, product manager, construction

management professor (colorado state university)

results

600% user growth over 4 years

90% user increase + 104% login increase in 2023

"Our whole business relies on you now"

tl;dr

As the second hire at ProNovos, I spent four years building the product from scratch as a scalable product that grew the user base by 600% and became the backbone of how construction companies manage their finances.

The real breakthrough happened during an exhausting week in a Costa Mesa Airbnb, fueled by Nespresso pods, when we discovered that all financial metrics collapse into two questions: "Am I making money?" (profit) and "Can I pay my bills?" (cash flow).

But the bigger discovery was about our users: we thought we were designing for CFOs with MBAs, but our actual users were 50-something project managers who learned finance on the job and didn't needed us to build dashboards. Learning to advocate for progressive disclosure over "everything on one screen," surviving a 2-month custom workflow disaster that taught me to lead instead of execute, and designing education directly into the product through tooltips and transparent calculations transformed how I think about design.

The result: contractors who say "our whole business relies on you now."

tl;dr

As the second hire at ProNovos, I spent four years building the product from scratch as a scalable product that grew the user base by 600% and became the backbone of how construction companies manage their finances.

The real breakthrough happened during an exhausting week in a Costa Mesa Airbnb, fueled by Nespresso pods, when we discovered that all financial metrics collapse into two questions: "Am I making money?" (profit) and "Can I pay my bills?" (cash flow).

But the bigger discovery was about our users: we thought we were designing for CFOs with MBAs, but our actual users were 50-something project managers who learned finance on the job and didn't needed us to build dashboards. Learning to advocate for progressive disclosure over "everything on one screen," surviving a 2-month custom workflow disaster that taught me to lead instead of execute, and designing education directly into the product through tooltips and transparent calculations transformed how I think about design.

The result: contractors who say "our whole business relies on you now."

Construction Runs on Excel and Prayer

Construction is one of the least digitized industries in America. Companies managing $50M-$500M in projects are still running everything in Excel: project budgets, cash flow forecasting, profitability tracking. All of it.

One of our early clients, Joe (owner of a design-themed subcontractor company in his 50s), described their spreadsheets perfectly: "You'd need a magic crystal to decipher them. There's always one guy who built it, and he's the only one it makes sense to." That's the industry we were trying to help.

I was hire #2, which meant I was in on sales calls from the very beginning—the really early ones where we had no idea what we were doing, submitted through a form on our website. I sat in on calls, took notes, recorded and reviewed them, and then spent hours on internal calls extensively arguing about what I was seeing.

Here's the pattern that emerged:

I learned to watch for when prospects stop asking questions around 30 minutes in and just politely say "looks good", you've lost them. It usually happened when we'd pile on features without connecting them to their specific pain. Real engagement looks like questions, pushback, even confusion. Passive acceptance? That's them being polite while planning their exit.

Construction Runs on Excel and Prayer

Construction is one of the least digitized industries in America. Companies managing $50M-$500M in projects are still running everything in Excel: project budgets, cash flow forecasting, profitability tracking. All of it.

One of our early clients, Joe (owner of a design-themed subcontractor company in his 50s), described their spreadsheets perfectly: "You'd need a magic crystal to decipher them. There's always one guy who built it, and he's the only one it makes sense to." That's the industry we were trying to help.

I was hire #2, which meant I was in on sales calls from the very beginning—the really early ones where we had no idea what we were doing, submitted through a form on our website. I sat in on calls, took notes, recorded and reviewed them, and then spent hours on internal calls extensively arguing about what I was seeing.

Here's the pattern that emerged:

I learned to watch for when prospects stop asking questions around 30 minutes in and just politely say "looks good", you've lost them. It usually happened when we'd pile on features without connecting them to their specific pain. Real engagement looks like questions, pushback, even confusion. Passive acceptance? That's them being polite while planning their exit.

The frustration

We'd spend time developing custom features prospects said they wanted—only to find out they weren't even using them. Or worse: we'd build exactly what they asked for, and they'd STILL not adopt it.

Something was fundamentally broken about our approach. We were being everyone's hands, not experts with a point of view.

But what contractors actually cared about kept coming back to the same things:

california dreaming

Startup life means time works against you. We needed to ship something testable, fast. Our PM lived in Costa Mesa, and honestly, it just seemed like a cool way to get away from everyday life.

So we rented an Airbnb house with 3 bedrooms. The CEO, a Construction Management Professor from Colorado State University, and I lived there. The PM came over every day.

We'd start at 8am and end around 11pm. Running on 4-5 cups of Nespresso Vertuo pods (the large 8oz ones!). We moved tables together in the small kitchen and set up monitors there, but I was mostly in the living room unless I had a question or we needed to discuss something. We only left the house once a day to grab dinner. During the day, we'd each take individual walks around the neighborhood to reset when our brains turned to mush.

It was exhausting, but it was also kind of beautiful. That forced, intense focus where you can't escape the problem.

I put together a mapping of ALL the financial elements scattered throughout our platform. We had a bunch of custom dashboards we'd built for different clients, and there was so much redundancy.

The PM and I worked through common contractor requests and the key metrics that provided value regardless of company size or financial expertise. We were trying to create comprehensive narratives around different aspects of their business: sales, revenue, billings, costs.

Sometime around day two or three, we realized: All of these financial elements can be grouped into either the "PROFIT" bucket or the "CASH FLOW" bucket. That's it. That's the entire mental model of a construction business.

Are you making money? (Profit)
Can you pay your bills? (Cash flow)

Everything else is just supporting detail for those two questions.

Speaking of cash flow...

This company pulled 5 people into the initial call. They wanted to see cash flow data their own specific way, something no other contractor in our experience looked at like this. But they were adamant: "We've always done it this way." Fine. It was just a design prototype, not actual development yet. We could explore it. So we did weekly calls for two months, We modified the cash flow module to fit their exact specific way. Every detail they asked for, we incorporated. Every adjustment they wanted, we made. We did everything exactly as they requested. After two months, they decided not to proceed. At first, I was just frustrated. All that work for nothing. But then I started thinking about why it failed. The real problem we missed is that users look for software to simplify their experience, not make it harder. By recreating their existing workflow exactly: • We still took them out of their comfort zone (new software = learning curve) • But we gave them zero UX benefit • Thus, the learning burden wasn't worth it If we're just mirroring what they already have, why would they switch? We needed to be the experts. We needed to say: "We've worked with 50+ contractors. Here's what works better. Here's why." Instead, we tried to please them by being their hands. What this taught me about designing for construction companies is that they want someone who understands their business better than they do, or at least when it comes to analytics and software. They don't have time to learn our complex tools. They don't want to recreate their Excel sheets in fancy software. They want us to show them the better path. That's what being a designer means in this context. Not just executing requests. Leading toward better solutions.

Speaking of cash flow...

This company pulled 5 people into the initial call. They wanted to see cash flow data their own specific way, something no other contractor in our experience looked at like this. But they were adamant: "We've always done it this way." Fine. It was just a design prototype, not actual development yet. We could explore it. So we did weekly calls for two months, We modified the cash flow module to fit their exact specific way. Every detail they asked for, we incorporated. Every adjustment they wanted, we made. We did everything exactly as they requested. After two months, they decided not to proceed. At first, I was just frustrated. All that work for nothing. But then I started thinking about why it failed. The real problem we missed is that users look for software to simplify their experience, not make it harder. By recreating their existing workflow exactly: • We still took them out of their comfort zone (new software = learning curve) • But we gave them zero UX benefit • Thus, the learning burden wasn't worth it If we're just mirroring what they already have, why would they switch? We needed to be the experts. We needed to say: "We've worked with 50+ contractors. Here's what works better. Here's why." Instead, we tried to please them by being their hands. What this taught me about designing for construction companies is that they want someone who understands their business better than they do, or at least when it comes to analytics and software. They don't have time to learn our complex tools. They don't want to recreate their Excel sheets in fancy software. They want us to show them the better path. That's what being a designer means in this context. Not just executing requests. Leading toward better solutions.

Speaking of cash flow...

This company pulled 5 people into the initial call. They wanted to see cash flow data their own specific way, something no other contractor in our experience looked at like this. But they were adamant: "We've always done it this way." Fine. It was just a design prototype, not actual development yet. We could explore it. So we did weekly calls for two months, We modified the cash flow module to fit their exact specific way. Every detail they asked for, we incorporated. Every adjustment they wanted, we made. We did everything exactly as they requested. After two months, they decided not to proceed. At first, I was just frustrated. All that work for nothing. But then I started thinking about why it failed. The real problem we missed is that users look for software to simplify their experience, not make it harder. By recreating their existing workflow exactly: • We still took them out of their comfort zone (new software = learning curve) • But we gave them zero UX benefit • Thus, the learning burden wasn't worth it If we're just mirroring what they already have, why would they switch? We needed to be the experts. We needed to say: "We've worked with 50+ contractors. Here's what works better. Here's why." Instead, we tried to please them by being their hands. What this taught me about designing for construction companies is that they want someone who understands their business better than they do, or at least when it comes to analytics and software. They don't have time to learn our complex tools. They don't want to recreate their Excel sheets in fancy software. They want us to show them the better path. That's what being a designer means in this context. Not just executing requests. Leading toward better solutions.

Speaking of cash flow...

This company pulled 5 people into the initial call. They wanted to see cash flow data their own specific way, something no other contractor in our experience looked at like this. But they were adamant: "We've always done it this way." Fine. It was just a design prototype, not actual development yet. We could explore it. So we did weekly calls for two months, We modified the cash flow module to fit their exact specific way. Every detail they asked for, we incorporated. Every adjustment they wanted, we made. We did everything exactly as they requested. After two months, they decided not to proceed. At first, I was just frustrated. All that work for nothing. But then I started thinking about why it failed. The real problem we missed is that users look for software to simplify their experience, not make it harder. By recreating their existing workflow exactly: • We still took them out of their comfort zone (new software = learning curve) • But we gave them zero UX benefit • Thus, the learning burden wasn't worth it If we're just mirroring what they already have, why would they switch? We needed to be the experts. We needed to say: "We've worked with 50+ contractors. Here's what works better. Here's why." Instead, we tried to please them by being their hands. What this taught me about designing for construction companies is that they want someone who understands their business better than they do, or at least when it comes to analytics and software. They don't have time to learn our complex tools. They don't want to recreate their Excel sheets in fancy software. They want us to show them the better path. That's what being a designer means in this context. Not just executing requests. Leading toward better solutions.

Here's something that surprised me: most contractors don't do what they're "supposed" to do financially. All that forecasting they should be doing in theory? They're not doing it. Even though "cash is king" and contractors obsess over cash flow, they don't do things like earned revenue analysis. Sometimes we'd have to teach them what it even means.

We realized: our users aren't CFOs with financial backgrounds. They're 50-something project managers who learned finance on the job.

This changed E-V-E-R-Y-T-H-I-N-G- about how we explained things. We weren't just building analytics. We were building an education tool. And we were building it for project managers on job sites, not CFOs in offices.

What We Left California With:

What We Left California With:

A framework of 9 standard dashboards organized around contractor workflows

Every dashboard grouped under either "Profit" or "Cash Flow"

The concept of an "Analytics Marketplace" where contractors could subscribe to standard dashboards

Wireframes for key screens

A subscription pricing model (spoiler: this didn't work, but we didn't know that yet)

A clear understanding that our users were PMs, not executives

california dreaming

Startup life means time works against you. We needed to ship something testable, fast. Our PM lived in Costa Mesa, and honestly, it just seemed like a cool way to get away from everyday life.

So we rented an Airbnb house with 3 bedrooms. The CEO, a Construction Management Professor from Colorado State University, and I lived there. The PM came over every day.

We'd start at 8am and end around 11pm. Running on 4-5 cups of Nespresso Vertuo pods (the large 8oz ones!). We moved tables together in the small kitchen and set up monitors there, but I was mostly in the living room unless I had a question or we needed to discuss something. We only left the house once a day to grab dinner. During the day, we'd each take individual walks around the neighborhood to reset when our brains turned to mush.

It was exhausting, but it was also kind of beautiful. That forced, intense focus where you can't escape the problem.

What We Left California With:

A framework of 9 standard dashboards organized around contractor workflows

Every dashboard grouped under either "Profit" or "Cash Flow"

The concept of an "Analytics Marketplace" where contractors could subscribe to standard dashboards

Wireframes for key screens

A subscription pricing model (spoiler: this didn't work, but we didn't know that yet)

A clear understanding that our users were PMs, not executives

We're Not Building "Just Dashboards"

Together with the PM, we agreed on one thing: If what we're building can be described as "just a dashboard," we don't need it.

Dashboards are static. You look at them once, think "cool, pretty charts," then never open them again. We needed something that prompted ACTION. The principle was straightforward: if something couldn't prompt users to do something, it was out.

The PM suggested that all information related to a specific dashboard should be available on a single screen — fewer clicks, better UX. This sparked multiple debates. Over Zoom, Slack, and in-person conversations.

His argument: everything visible upfront. All data on one screen. No clicking required. Dense but "efficient."

My argument: progressive disclosure. Essential KPIs at top. Visualizations showing trends. Detailed breakdown below. Tooltips and fly-outs for education when needed.

What I actually said (paraphrased): "Our users aren't data analysts. They're 50-something project managers who've been in construction for 30 years but don't have financial backgrounds. They're used to Excel spreadsheets that need a 'magic crystal to decipher. If we overwhelm them with too much information upfront, they won't come back. It'll be 'another thing they need to do now.' Yes, fewer clicks sounds better. But the time saved clicking is lost when they spend 10 minutes trying to figure out where to start or what anything means."

Anyway, I initially gave in and complied on a few dashboards. Then, after a very short period, he realized that users were getting lost in the abundance of information and functionality.

So we redesigned those modules. The final design featured just the essential KPIs and visualizations at the top, with an extensive breakdown table at the bottom. To address the potential issue of overwhelming users, we included fly-out windows, hover states, and tooltips. These elements also served as educational tools, offering additional information to users without analytical expertise or financial backgrounds.

The mail lesson I learned: advocate for your expertise, even when it's uncomfortable.

Early in my career, I'd comply when someone senior disagreed. Then I'd watch users struggle. I learned that being underestimated as a designer, as a woman, and as a foreigner doesn't mean being wrong. My job isn't to be someone's hands. It's to be an expert. And sometimes that means pushing back until you're heard.

So we redesigned those modules. The final design featured just the essential KPIs and visualizations at the top, with an extensive breakdown table at the bottom. To address the potential issue of overwhelming users, we included fly-out windows, hover states, and tooltips. These elements also served as educational tools, offering additional information to users without analytical expertise or financial backgrounds.

The mail lesson I learned: advocate for your expertise, even when it's uncomfortable.

Early in my career, I'd comply when someone senior disagreed. Then I'd watch users struggle. I learned that being underestimated as a designer, as a woman, and as a foreigner doesn't mean being wrong. My job isn't to be someone's hands. It's to be an expert. And sometimes that means pushing back until you're heard.

The Problem We Didn't Anticipate

After our initial launch for user testing and prospect presentations, we kept hearing requests for guidance. Not just on navigating the dashboards but on understanding the financial and construction concepts behind the metrics.

Users would ask us: Where does this metric come from? How is this calculated? Is 8% profit margin good? Why is this number different from what I expected?

At first, I thought: These are smart people running multi-million dollar companies. Surely they understand basic financial metrics? Then I remembered what we learned in California: our users are project managers, not CFOs.

A CEO of one of our client companies said something that stuck with me: "I have to spend hours every week with my PMs getting data and asking them questions about it, only to realize they don't actually understand it. This makes conversations long and difficult." That's when it clicked: we weren't just building analytics. We were building the bridge between financial data and the people who needed to use it but didn't have the training.

How We Built Education In

I developed a simple rule:

Financial concepts → EXPLAIN
Profit margin, earned revenue, cash flow forecasting, cost variance

Construction concepts → DON'T EXPLAIN
Change orders, subcontractor payments, billing schedules

Project managers live in construction every day. They don't need us to explain their industry. But many of them learned finance on the job, not in school.

We designed three levels of education:

LEVEL 1 - HOVER (Quick context)

"This is the summary of the upcoming 13 weeks. Total amount includes transactions beyond the weeks of 11/4 and equals $1,192,780.00"

"This is the summary of the upcoming 13 weeks. Total amount includes transactions beyond the weeks of 11/4 and equals $1,192,780.00"

LEVEL 2 - CLICK (Detailed explanation)

"The revenue earned on each job based on your percent complete. (Job Cost to Date ÷ Projected Final Cost) ÷ Revised Contract Amount

LEVEL 3 - LEARN MORE

Collected information feeds into other parts of the platform, like the Profit Margin chart, to help users make informed decisions.

Three layers of depth for three levels of curiosity. Never patronizing, never overwhelming. Education when they need it, invisible when they don't.

We also designed the system so that when users adjust budgets or spending, they can select a reason (the root cause) for each change. It transformed simple number adjustments into insightful documentation.

That captured information gets presented as summary charts to analyze reasons behind budget changes. It feeds into other parts of the platform, like profit margin analysis, to help users make informed decisions for future projects. The system learns with every adjustment. It becomes more valuable over time.

Three layers of depth for three levels of curiosity. Never patronizing, never overwhelming. Education when they need it, invisible when they don't.

We also designed the system so that when users adjust budgets or spending, they can select a reason (the root cause) for each change. It transformed simple number adjustments into insightful documentation.

That captured information gets presented as summary charts to analyze reasons behind budget changes. It feeds into other parts of the platform, like profit margin analysis, to help users make informed decisions for future projects. The system learns with every adjustment. It becomes more valuable over time.

WHAT DIDN'T WORK

The Netflix model I loved (that didn't happen)

I wanted to build the product like Netflix. The vision: dashboards recommended to users based on their usage patterns, "You might also like..." suggestions, release a new dashboard every week to keep it fresh.

Why it didn't work:

There's only so much data we can show. More data doesn't equal good. Most contractors aren't interested in discovering new dashboards every week. They have their core metrics they care about. They want reliability and consistency, not novelty. I was designing for my interest in data, not their actual workflow.

The subscription marketplace failed

Remember how we came out of California with this "Analytics Marketplace" concept? Contractors would subscribe to specific dashboards, monthly subscription fee, modular approach? Yeah, well, contractors never actually adopted that model.

The frustration

We'd spend time developing custom features prospects said they wanted—only to find out they weren't even using them. Or worse: we'd build exactly what they asked for, and they'd STILL not adopt it.

Something was fundamentally broken about our approach. We were being everyone's hands, not experts with a point of view.

But what contractors actually cared about kept coming back to the same things:

Lo-fidelity wireframes. For the landing page, we drew inspiration from Netflix for the layout, showcasing featured content at the top of the page and placing recommended reports at the bottom, below the dashboards actively used by the user. This setup makes it easy for users to find what they need and discover new features, similarly to how one finds new shows to watch on a streaming platform.

We didn't commit to the idea of releasing new ones regularly. And honestly, they didn't want a marketplace, they just wanted the full suite of tools available. So now everything is just available, and users can hide the ones they don't need. Less elegant from a product strategy perspective. But actually what users wanted.


Some contractors still want to modify standard dashboards and create their own custom views. We gave them that ability. The process was HORRENDOUS. Nine steps involving leaving our application, going into another application (the dashboard creation backend), creating it there, saving it, going BACK into our application, finding it in drafts, publishing it, going into a standard dashboard, clicking settings and replacing it with the published dashboard.

Jeez.

I actually JUST redesigned this monstrosity.

But here's what this taught me: sometimes you have to ship something imperfect because of technical constraints, then come back and fix it when you have the resources. The important thing is recognizing what's broken and advocating to fix it.

We didn't commit to the idea of releasing new ones regularly. And honestly, they didn't want a marketplace, they just wanted the full suite of tools available. So now everything is just available, and users can hide the ones they don't need. Less elegant from a product strategy perspective. But actually what users wanted.


Some contractors still want to modify standard dashboards and create their own custom views. We gave them that ability. The process was HORRENDOUS. Nine steps involving leaving our application, going into another application (the dashboard creation backend), creating it there, saving it, going BACK into our application, finding it in drafts, publishing it, going into a standard dashboard, clicking settings and replacing it with the published dashboard.

Jeez.

I actually JUST redesigned this monstrosity.

But here's what this taught me: sometimes you have to ship something imperfect because of technical constraints, then come back and fix it when you have the resources. The important thing is recognizing what's broken and advocating to fix it.

WHAT DIDN'T WORK

The Netflix model I loved (that didn't happen)

I wanted to build the product like Netflix. The vision: dashboards recommended to users based on their usage patterns, "You might also like..." suggestions, release a new dashboard every week to keep it fresh.

Why it didn't work:

There's only so much data we can show. More data doesn't equal good. Most contractors aren't interested in discovering new dashboards every week. They have their core metrics they care about. They want reliability and consistency, not novelty. I was designing for my interest in data, not their actual workflow.

The subscription marketplace failed

Remember how we came out of California with this "Analytics Marketplace" concept? Contractors would subscribe to specific dashboards, monthly subscription fee, modular approach? Yeah, well, contractors never actually adopted that model.

the outcome

Over four years, we grew the user base by 600%. In 2023 alone, we released 3 new modules that resulted in a 90% increase in user base and a 104% increase in user logins.

Those numbers are great. But honestly, what I care most about is what users actually said:

On cash flow:
"We can clearly see what's coming in and what's going out over the next 30 days. That's the kind of confidence we have now."

On analytics:
"It's not just 'What's our margin?' anymore. It's 'Why is our margin changing?' That's the conversation now."

On time savings:
"We've gone from spending hours on data extraction and manual reporting to having everything we need at our fingertips in real time. It's been a game-changer."

On improvement:
"How are you going to improve something that you don't measure, especially measuring properly? ProNovos is doing that for us."

Every time users talk about how their whole business relies on us now, or how they use us during their monthly project reviews, it makes me believe we're doing the right thing.

What i learned

Your users might not be who you think they are

We thought we were designing for C-suite executives with financial backgrounds. We discovered our actual users are project managers who don't have financial training but are suddenly responsible for managing budgets, cash flow, and profitability. This changed what we showed, how we explained it, the language we used, and the level of education we built in.

Matching existing workflows isn't improvement

The 2-month custom workflow disaster taught me this the hard way. When someone says "we've always done it this way," that's not a feature request—it's a red flag. Your job as a designer is to be the expert who's seen 50+ contractors and knows what works better. Lead toward better solutions, don't just execute requests.

Advocate for your expertise, even when uncomfortable

Being underestimated doesn't mean being wrong. The PM knew business and construction; I knew how to design for humans. Pushing back was uncomfortable, but necessary. Eventually, I was vindicated when we redesigned it my way and users stopped getting lost.

Education IS design, not a nice-to-have

In high-stakes contexts like finance, transparency and education aren't extras—they're the foundation of adoption. Design them in from the start. The CEO who said "I spend hours every week with my PMs only to realize they don't understand the data" taught me that our job was building confidence, not just showing numbers.

the personal impact

Why did this project matter to me personally? Honestly? I'm so invested in this company it's insane.

I love analyzing data and seeing patterns. I love financial data. Fintech seems very cool to me, and this was the closest I could come to it. How do you present data in a way that makes sense and looks engaging and provides insights?

These projects make my brain steam. I'm not a super math person, so sometimes dealing with numbers or creating data flows makes my brain a slushy. But those are my favorite kinds of projects: where I think until I get a headache, then have a meltdown, take a break, and come up with something awesome the next day (or next week).

I mean, I designed all those modules. But the whole product is like my child.

what i'd tell myself week 1

Push back.

Don't just agree silently because other people should know better. They probably do, in their own area of expertise.

You're hired to be an expert in YOUR area, not to be someone's hands.

That lesson took me two years and a lot of uncomfortable conversations to learn. I wish I'd learned it sooner.

next: rockitboost

next: rockitboost

next: rockitboost

next: rockitboost

© 2025