About
I lead product and technology through complexity.
I'm Manuel Benancio, also known as Kembec. I currently work as a CTO, leading across product, technology, operations, and organizational design.
My background is deeply technical, but my work is no longer defined only by the systems we build. It increasingly involves choosing which problems matter, understanding customers and business constraints, creating direction, designing how teams make decisions, and connecting strategy with execution.
I see technology as part of the product system — not as a separate function.
Esta página también está en español.
Scope of work
Today that means product direction and technology leadership for connectivity and IoT products, where the product has an operational floor that never pauses: provisioning, activation, billing correctness, partner integrations, and compliance. It covers the roadmap and the organization that has to deliver it — how teams are structured, how decisions get made, and what we deliberately choose not to do.
I work in Spanish and English, from Peru, with teams and partners across Latin America.
From builder to leader
I started by building. Small sites in 2008, then backend systems, then full applications, then the infrastructure underneath them. That period taught me something I still rely on: how decisions actually get executed, and what it costs when a plan ignores the shape of the system it lands on.
Co-founding a company in 2018 changed the question. Building well stopped being sufficient, because the harder problem was deciding what deserved to be built at all, with limited people and real customers waiting. Consulting work from 2020 sharpened it further: different businesses, the same recurring gap between a strategy and an organization capable of executing it.
The technical depth did not become decoration. It is what lets me price a decision honestly — what it forecloses, what it costs to reverse, what operational load it creates two years out. But the depth is now in service of product judgment, not the destination.
Areas of focus
- Product strategy and direction
- Choosing which problems matter, naming what we refuse, and keeping those choices legible enough that teams can act on them without asking permission.
- Product and engineering operating models
- Decision rights, shared ownership of outcomes, and how continuity work gets funded before it becomes an incident.
- AI-enabled operations and products
- Where cheaper implementation actually changes a business, and where the real constraint is workflow, trust, and adoption instead of capability.
- Platform products
- Reusable capabilities with named consumers, governance that holds, and leverage you can express per consumer.
- Organizational design
- How teams are shaped, how decisions travel, and how technical judgment stays close to the choices it should inform.
What I argue for
These are positions, not slogans. Each one is defended somewhere on this site, with the reasoning and the limits stated.
- Technology is part of the product system, not a function underneath it.
- As implementation becomes cheaper, judgment becomes more valuable.
- The relevant speed is learning speed, not delivery volume.
- Product and engineering need different specialties and shared ownership.
- Operating models decide whether strategy ever becomes execution.
- AI changes organizations, not only interfaces.
- Complex products need technical, operational and organizational judgment at once.
Selected trajectory
- 2024 — CTO, Guinea Mobile An MVNO platform where other companies build connectivity and IoT products. Product, technology, operations and organizational design.
- 2020 — Technology consultant, Grupo Anta Digital transformation work across sectors, pairing technical delivery with strategy.
- 2018 — 2023 Co-founder and CTO, Syma POS and electronic invoicing for the Peruvian market under SUNAT compliance rules. Intellectual property sold in 2023.
- 2014 — 2018 Independent developer and consultant Backend systems, process automation and full applications, moving from delivery into technical decision-making.
The long, personal version of this story — including the parts that were not a career move — is kept at lore.
Domains of experience
Telecommunications and IoT, SaaS, POS and electronic invoicing under tax regulation, e-commerce, and developer tooling. Domain knowledge matters because it proves a way of working survived real constraints. It is context for the work, not the definition of it — which is why it lives in domains rather than at the top of this page.
Evidence
One system, not three functions
I do my best work where product, technology, and organizational capability are treated as one system—especially in companies whose products carry real operational complexity.
The most useful version of my technical background is not as a separate delivery function, but as an input into product direction, organizational design, and company-level decisions.