
Aspinity
Led product strategy for Astrl — a support ecosystem helping ML engineers overcome the AnalogML knowledge gap
00
problem
Aspinity's AML100 chip enables AnalogML—machine learning on raw analog data—extending battery life by up to 20×. Clients wanted more control over their data and software, but AnalogML is a niche domain: most engineers face a steep knowledge gap, and cross-functional development (ML engineers, signal experts, hardware teams) requires coordination that wasn't supported.
solution
Astrl addresses three interconnected areas. Contextual guidance helps users understand where analog methods differ from standard ML, especially in feature engineering—short assist-mode pop-ups that show rather than tell, coupled with the UI they describe, plus flowcharts in project notes and links to documentation. A supportive community lets peers and Aspinity experts share knowledge with privacy controls for proprietary work. Intuitive collaboration moved the platform from local desktop to cloud: teammates can be added as collaborators with flexible permissions, and change history shows what was edited when users step away and return.
my role
product manager
industry
Semiconductors & AI
timeframe
Jan 2021 - Aug 2021
team members
Raga Kavari, Sofia Kirkman, Animesh Singh, Linda X Mansilla
outcome snapshot
- 20+ usability tests - 19 expert interviews - 6-month research → 6-month design - Astrl prototype
project snapshot
8-month MHCI capstone with Aspinity, a Pittsburgh-based AI/ML company. Aspinity's RAMP technology enables AnalogML—performing machine learning directly on analog sensor data, reducing always-on system power by 95%+. Their chip powers applications in Voice-First, Acoustic-Event Detection, and Vibration Monitoring. Clients wanted more control over their data and software, but engineers faced a steep learning curve in this niche domain. Our team of five (PM, design lead, design technologist, research co-leads) designed Astrl: an ecosystem of support combining built-in walkthroughs, community-based learning, and flexible collaboration tools.
research process
Research methods: 5 competitive think-alouds (Aspinity engineers on EdgeImpulse, Watson ML), 10 speed dating sessions (storyboards across 7 application phases), 2 Wizard of Oz (modals dragged on-screen during tests), 20 usability tests, 10 semi-structured interviews, 4 contextual inquiries, 19 expert interviews, 20 literature reviews. Early pretotyping tested open-box experience and quick-start guides to validate trust and onboarding assumptions.
Participants: Academic researchers, CMU alumni, personal network, LinkedIn recruitment, Aspinity client contacts, Aspinity internal teams (Director of Product, Signal Processing, Madhumita Harish, Glen Clark, software architect, CEO/CTO).
Application development phases (from research): Training and onboarding → Data acquisition and cleaning → Feature engineering and selection → Model selection → Model training → Model testing/evaluation → Deployment to hardware.

insights:
Niche domain knowledge: AnalogML is new; clients need to understand high-level relationships and requirements of working with analog data and hardware. Users preferred learning through hands-on experience with context and support along the way—not upfront education.
Show, don't tell: Users closed lengthy modal callouts quickly but later wanted help back. Solution: shorter pop-ups, GIFs and pictorial communication, contextual callouts instead of walls of text.
Cross-functional teamwork: End-to-end development involves ML Engineering, Data Preprocessing, and Hardware Engineering; no single person owns all steps. Personas (Robin, Cam, Dani) helped define role-based needs.
Privacy and modality: ML engineers were concerned about data, project privacy, and viewing permissions—especially for forum questions. GUI vs IDE preference depended on step: GUI for existing models, IDE-first when starting from scratch.
Manager vs user tasks: Users confused by project overview with pre-set metrics—felt that was a manager-level decision. Needed clear visual treatment for pre-filled fields.
Manual tasks: Many frictions and inefficiencies; engineers restart processes after changes, lack context, and spend time on research and experimentation.
Spotlight story: show, don't tell
In the final sprint, the team tackled two questions: How might we help new users navigate the feature engineering section with contextual support? And how might we support users bringing in human help during application development? I helped prioritize both and the team designed for them simultaneously.
The team had learned something surprising: users wanted to skip the education and jump right in, but when they did, they didn't know where or how to apply analog methods. They recognized that the overall analog ML process doesn't differ from standard ML—but they couldn't tell which steps had analog-specific elements. Confusion concentrated in feature engineering. Users appreciated the pop-ups and interactive flowchart, but they didn't understand what they needed to do differently from their usual workflow. I was struck by how clearly users wanted to be shown, not told. The team shortened the assist-mode pop-ups, coupled them with the actual buttons on the page, and added links to documentation for those who wanted more. They also placed a use-case-specific flowchart in project notes; users liked it but wished for a button on the page for easier access.


On the collaboration side, the team had originally envisioned a local desktop app. Spring research showed that developing a model and putting it on hardware is a team effort—within client teams and between clients and Aspinity. We moved the platform to the cloud so teams could work together online. Collaborator access was a hit: users said it was extremely helpful for getting multiple eyes on the work. They also wanted a change history—when they walked away and came back, they needed to know what had been edited. We designed for that, plus project notes as documentation and a message center for team updates.

As the team finalized the prototype, I facilitated Walk-the-Wall sessions to plan the presentation and client report. The team took the audience through an engineer's journey of developing an analog ML product, and handed off a design system so Aspinity's future teams could build on the work. That final sprint—feature engineering callouts, collaboration features, and preparing for takeoff—was where months of research came together.
final solution: ASTRL
process snapshot
01

02

03

takeaway thoughts
Niche technical domains need solutions that support diverse expertise and shared workflows, no single person owns the full process
Contextual guidance, community, and collaboration close knowledge gaps without overwhelming users
Aligning user needs with business goals in an 8-month cycle sharpens product strategy and prioritization




