About
I build the bridge between what a business needs and what gets built.
I help businesses identify problems, validate ideas, design solutions, and build products people actually use.
Jos, Nigeria
Haruna Huyad Gashow
The short version
Business-minded product professional who bridges people, process, and technology. I translate ambiguous business problems into validated requirements, clear user stories, and shippable product decisions — partnering with stakeholders, users, designers, and engineers to deliver software that solves the problem it set out to solve.
The longer version
I started in computer science expecting the hard part to be the code. It wasn't. The hard part was watching capable teams build carefully specified software for problems nobody had confirmed existed — and then explain the failure as a delivery issue.
So I moved upstream. I learned to run the conversation that happens before the first commit: interviewing the people who do the work, mapping the process as it actually runs, separating what stakeholders ask for from what they need, and writing requirements that a business owner and an engineer can both sign.
Because I can still build, that analysis doesn't stop at a document. On Tally, Zemo and Ease Voting I ran the whole arc — discovery, requirements, design, engineering, UAT — which means the intent behind a decision survives all the way into production instead of being negotiated away in handoff.
What I offer a team is rare in one person: the commercial instinct to ask whether something should exist, the research discipline to prove it, the design sense to make it legible, and the engineering credibility to be trusted by the people who build it.
How I work
- 01
Validate before building
Evidence is cheaper than code.Every build starts with a hypothesis and the smallest test that can disprove it. Prototypes, interviews, and clickable flows retire risk before an engineering hour is spent.
- 02
Users first, always
The user defines the requirement.Requirements are discovered in conversation, not invented in a document. I sit with the people doing the work until their real job-to-be-done is unmistakable.
- 03
Business before features
A feature without a business case is a liability.Each scope decision maps to a commercial outcome — retention, revenue, cost, trust. If it maps to nothing, it does not enter the roadmap.
- 04
Data-driven decisions
Opinions open the debate; data closes it.Qualitative research plus behavioural signal decide prioritisation. I instrument early so the next decision is better informed than the last.
- 05
Simplicity wins
Clarity beats completeness.The strongest requirement set is the one with the least surface area. I cut aggressively so the core promise stays legible to the user.
- 06
Continuous iteration
Shipping is the beginning of learning.Launch opens the feedback loop: UAT, usage review, interview, refine. Products earn their scope over time rather than assuming it upfront.
Capabilities
Grouped by the business question each one answers.
Business Analysis
Can you define the right problem?
- Requirement elicitation
- Stakeholder management
- Business process analysis
- Functional documentation
- Requirement validation
- Process improvement
- Gap analysis
Research & Discovery
How do you know it's real?
- User interviews
- Hypothesis testing
- Customer research
- Usability testing
- Competitive analysis
- Synthesis & insight mapping
Product Strategy
What should be built, and when?
- Product discovery
- Roadmap prioritisation
- User stories & acceptance criteria
- Scope definition
- Success metrics
- MVP framing
Engineering
Can you build it, credibly?
- TypeScript
- React & Next.js
- Python & Django
- PostgreSQL & SQL
- Supabase
- Git & GitHub
- API design
Design
Will people understand it?
- Product design
- Wireframing & prototyping
- Interaction design
- Design systems
- Figma
- Accessibility
Leadership & Communication
Can you carry a room?
- Workshop facilitation
- Cross-functional collaboration
- Mentoring
- Technical writing
- Executive communication
- Seminar facilitation
Outside the work
I mentor developers on requirement analysis and product thinking, facilitate tech seminars in secondary schools, and served as Technical Officer for the Google Developers Community at PLASU. Teaching keeps my explanations honest — if a sixteen-year-old can't follow the reasoning, it probably isn't clear enough for a stakeholder either.