back
OICO
EXTENDED version
About the company
Oico built a B2B construction-materials marketplace connecting builders, stores, and deliveries in Brazil, turning a manual, service-based operation into a product built to scale. Backed by Y Combinator, Valor Capital, and Tiger Global.
—
Tags
The product had market fit and serious funding. It also ran on people doing by hand what it claimed to automate.
I joined Oico as Lead Product Designer, part of a senior product team. It was a Y Combinator company that had just raised a US$5.5M seed led by Valor Capital, with Tiger Global, a B2B marketplace for construction materials connecting builders, stores, and deliveries, with clients that included names like Loft, Blink, and Reformei. Product-market fit was real and paying customers were real. But the product was a shell that worked because people made it work, and my job was to lead the design that turned that shell into something that could scale. This is the long version, with the mechanics of that work and how design carried a validated MVP toward a product built for growth.
The short version of the problem: the company had grown by starting as a service, doing everything manually, and was now trying to become a product. When I arrived it was stuck between the two. The operation worked, but the software was mostly a transmission line, and people did the real work behind it.
Context and problem
Brazil's construction sector runs on paper, WhatsApp, and memory, and its language is deliberately imprecise. A "Bahian brick" in São Paulo is a "mineiro brick" in Rio. A "cement bag" is 25kg or 50kg depending on the supplier. A foreman orders "that iron" and expects the store to know the gauge from context. Before Oico, every request passed through three or four people interpreting WhatsApp messages before it became a real purchase.
That imprecision was the trap. Forcing 50,000+ independent suppliers to standardize their terms would break decades of practice and lose users on day one. But without structure, every order was a guessing game. So the company had solved it the only way it could at first, with people. Customer Success read every order, interpreted it, confirmed it, and chased down the ambiguities by phone. It worked, and it did not scale, because growth meant hiring another person for every increase in volume.
That is the state I joined: a validated product that was really a manual service wearing a thin software layer. The design problem was to move the interpreting work off the people and into the product, and to do it without forcing the sector to change how it spoke.
How I got to the product
I worked inside a traditional product chain, and my role in it was specific. Product brought the premises, the problem to solve and the constraints, and I turned those into flows, screens, and documentation. In practice that was rarely a handoff in isolation: there was a working conversation with product and engineering to pressure-test an approach and find the best way through it, then, once my part was ready, the same conversation again with engineering to make it buildable. Decisions were collective. My contribution was translating them into a product that held together and could grow.
Two things shaped how I approached it. The first was that the errors almost always started at the very first message. A builder wrote "500 Bahian bricks," and the ambiguity in that phrase, six holes or nine, red or white, rippled through every step after it. If the product could resolve the ambiguity at the source, most of the downstream rework would disappear. The second was that the existing design could not carry that load. The design system was minimal and the screens were simple in a way that suited an MVP but not a product at scale. That gap became a large part of my work.
WHAT I BUILT
My contribution had two intertwined threads: maturing the design foundation so it could support scale, and designing the flows that moved interpretation from people into the product. They depended on each other, so I treat them together.
Maturing the design system
The design system I inherited was basic. It had few components, none of the more complex ones a scaling product needs, and it was built without the structure, auto layout and the rest, that keeps design work fast and consistent. In practice that slowed every delivery and made the interface fragile as the product grew.
More consequentially, the form structures were too simple for what the product now had to do. An MVP form can be thin, because a human on the CS team catches whatever it misses. A form that has to ask the right question on its own, without that human, needs more: room for validation, for informative layers, for redundancy, for the states that handle when something is unclear or wrong. I rebuilt the components and the form patterns to carry that weight, so the interface could hold the complexity the product was starting to absorb instead of pushing it back onto people. Maturing the system was the precondition for everything the product needed to do next.
Moving interpretation into the product
With a foundation that could carry it, the core design work was taking the interpreting out of people's heads. The clearest example was the order itself. Instead of a CS person reading "500 Bahian bricks" and starting a chain of confirmations, the product mapped the request to a specific SKU based on region and past purchases, then confirmed it in plain language: "500 nine-hole ceramic bricks, 14x19x19cm, correct?" The builder confirmed with one tap. What used to take hours of back-and-forth took seconds, and each correction taught the system to guess better next time.
That same principle, resolve ambiguity at the source and give each side a structured version of the truth, extended across the flows I designed. Stores stopped receiving vague WhatsApp messages and started receiving specified orders they could act on. Recurring purchases, the materials a builder bought every week, collapsed into a single tap instead of a rebuilt list. Drivers saw their day and their route in a structured view rather than a paper list. In every case the move was the same: take the ambiguity off the person and put it into the system, where structure could hold it.
Results
The same CS team handled far more volume without growing, because the product finally did the interpreting work instead of transmitting it. Orders that took four hours of human back-and-forth resolved in about fifteen minutes, CS intervention fell from every order to a small fraction, and the same team handled many times the volume it used to. A foreman could order in the morning and have materials on site by afternoon, which in construction is the difference between a working day and a stopped one.
Order processing: 4h to 15min.
CS intervention: 100% to 13% of orders.
Volume: 7x more orders handled by the same team.
Manual work: 85% reduction.
What I learned
This one pulled together what the others taught me. In construction, as in nonprofit fundraising and rental guarantees before it, the instinct is to fix chaos by imposing a standard, and it never works, because people have decades of reasons for doing things their way. What works is building a system that absorbs the ambiguity and gets smarter with use, meeting people where they are and quietly moving the structure into the product, not onto the user. But this case taught me something more specific too: that a system can only absorb complexity if its foundation is built to hold it. The interpreting could only move into the product once the design underneath, the components, the forms, the states, was strong enough to carry it. Ambition at the flow level depends on maturity at the system level. After four products in messy, high-variability sectors, that is the pattern I trust most.
FACT SHEET
Role: Lead Product Designer, part of a senior product team
Period: 2022 to 2023
Context: B2B construction-materials marketplace, Brazil. Y Combinator company; US$5.5M seed led by Valor Capital, with Tiger Global. Clients included Loft, Blink, Reformei.
Scope: Led the design that carried a validated MVP toward a product built for scale. Matured the design system and form patterns; designed the flows that moved order interpretation from the CS team into the product. Worked in a collaborative product, design, and engineering chain.
Ways of working: Remote, traditional product-to-design-to-engineering flow, documentation-driven.
Domains and keywords: B2B marketplace, design systems, product design, scaling design, workflow design, ambiguity and structured data, construction tech.
Outcomes: order processing 4h to 15min; CS intervention 100% to 13% of orders; 7x more orders at the same headcount; 85% reduction in manual work.
