Episode #64: Building Emerging-Technology Products from Problem to Buy-In with Joseph Argiro

Emerging technology does not remove the need for product fundamentals. It makes them more important. In Episode #64, Joseph Argiro lays out a grounded approach to validating problems, structuring a product vision, working across functions, and earning support without formal authority.

What you'll learn

• How startup and enterprise environments develop different product skills

• Why a landing page can be a useful early test before building a full product

• How to move from market research and customer interviews into requirements and prototypes

• How a North Star and a small set of epics make product vision actionable

• Why education can create stronger stakeholder buy-in than direct instruction

Combine startup resourcefulness with enterprise structure

Argiro traces his product path to an integrated business and engineering program in college. His capstone was a marketplace for college tours, similar in structure to the platform businesses receiving attention at the time. Building it taught him product work through direct practice. The business eventually encountered legal and growth problems, and he sold the software for far less than its potential value. He then worked at Vanguard before joining the crypto startup ICO Alert as its second employee. As the company grew, his work moved into an early-stage product role. He later held a more formal product management position at Hewlett-Packard before returning to web3 at Enter The Void.

Those environments offered contrasting lessons. A startup demands resourcefulness because specialists may not be available. Product managers must operate with ambiguity, learn independently, and find people who can fill knowledge gaps. An enterprise provides more resources and formal training, but may offer less autonomy. The useful goal is to combine self-directed problem solving with repeatable product discipline.

Validate the problem before expanding the solution

Argiro's zero-to-one process begins with three questions: what market is the team entering, what problem is it solving, and who is the target customer? These questions prevent a new capability from becoming the strategy by default.

Before committing to a full build, he suggests creating a landing page to gauge whether the target market is interested in the proposed solution. That early signal is not final proof, but it can show whether a problem appears worth deeper investigation. The next step is direct customer interviews focused on pain points.

From there, Argiro creates a product requirements document that explains why the product is being built and records high-level features and requirements. This gives the broader team a shared view of scope and purpose. He then moves into wireframing and prototyping, beginning with pen and paper before mapping the user flow and rough interface in tools such as Miro or Lucidchart. Only after that foundational work does he bring in more design and engineering resources.

Turn a North Star into manageable work

A product vision must be specific enough to guide decisions. Argiro starts with a North Star describing where the team wants to go, then works backward into epics. Each epic represents a larger deliverable or theme that can contain many smaller requirements and tasks.

Breaking the vision into a limited set of epics lets stakeholders see the destination and the major bodies of work required to reach it. The structure also connects strategy to execution without reducing the vision to an unprioritized task list.

Emerging technology adds another challenge: documentation may be limited because important capabilities have not been built before. Argiro contrasts that with mature technologies, where teams can rely on established tools and references. In web3, he follows public discussion and multiple newsletters to track changes. He also values the ecosystem's practice of building in public because open ideas and customer reactions can tighten the feedback loop.

Earn cross-functional buy-in through education

Argiro describes work on an NFT infrastructure protocol and a private developer alpha. Product and marketing had to build a funnel for qualified developers, while marketing needed enough technical context to explain the program's benefits. His role included translating technical requirements into language that developers, marketers, sales teams, and a broader audience could understand.

That translation is central to his view of product management. Earlier in his career, he tried to influence teams through direct statements about requirements and what needed to happen. Over time, he found education more effective. Instead of relying on a hard sell, he gives stakeholders the background and reasoning that explain why a product should move in a particular direction or order. People can then reach an informed conclusion and develop genuine ownership of the decision.

He applies the same learning mindset to technical growth. Working on infrastructure and developer tools required him to understand compilers and product architecture more deeply, even without becoming the person writing the code. That knowledge helped him collaborate with engineering and explain how technical pieces combine to produce the end experience.

Keep fundamentals at the center of emerging tech

Argiro's approach is a reminder that novel technology still needs familiar product work: precise problem definition, early validation, customer contact, visible structure, cross-functional translation, and thoughtful buy-in. Asking many questions helps a PM understand each teammate's strengths and limitations, then fill gaps resourcefully.

Listen to Episode #64 with Joseph Argiro for the full discussion on startup learning, web3 product development, technical growth, and influence: play the episode.