Nate Pershall

Myota started with 4 great ingredients: Seasoned tech-forward leadership, an innovative piece of IP, the inventor as lead developer, and the goal to make a good idea into a great product.

By the time I joined the Myota team they had a strong proof of concept and the financial backing to start turning concept into a successful information security product.

Their initial goal was getting some UI on that proof of concept. But, it wasn’t long before we had the team in a week long discovery sprint to map the entire scope of a product… A product that had all assumed they understood.

What followed was an eye-opening journey through the assumptions every team makes: Who are our primary customers, how it will work/look, how much work will it take, what we’re building it with/on/in, what are our biggest risks, where are our best opportunities, and of course “I thought we were almost done that.”

If you’re not familiar with Jeff Patton or his recipe for Story Mapping your product, it’s a pretty intuitive idea. Especially if you’ve been building solutions for awhile. While it can be intimidating at the outset, and even daunting at times, it’s probably the most effective way to examine all the factors that necessary for a successful MVP – From why someone would use your product to all the parts & people you’ll need to build it..

In a nut-shell, Story Mapping is just telling the story of your product as you understand it: documenting each step of that story, then examining those steps for details about how each step works, assumptions that need vetting, and the missing knowledge that will require discovery work.

The special ingredient, of course, is having a skilled UX practitioner on hand that can sense ambiguity and prompt you with the kind of questions that get you explaining, or, maybe, scratching your head… as well as documenting every explanation and head scratch.

Committing to the Sprint

Initially a Story Mapping sprint seems easy–just answer some questions, mark up some post-it notes, and call it a day. But often enough it becomes quite challenging.

The first thing we recognize is everyone has a slightly (or totally) different idea of what’s planned: How will it look, how it will work, and how long it will take to build… aaaaannnd I’m here for it!

Story Mapping your customer’s path to and through your product is the single best way to get to know what you’re building, the team that’s building it, and yourself.

Luckily, Myota was a well outfitted with problem solvers from our deeply analytical Dev Ops leader, Bob, to our business-minded slinger-of-soft-skills CEO, Trip, and our deeply knowledgable tech inventor, Jeyoon… We had all we needed to think deeply about who, what, how, when, and where of building an MVP.

Weeks later we were working steadily through the product we planned refining architecture, wireframes, users flows, and hashing out UI details for browser-based & OS-based solutions.

Process Diagrams, Wire Flows, & Architecture

The Story Mapping Exercise gave us a pretty good idea of all the moving parts, raised awareness around some critical unknowns, some risky assumptions, and allowed us to start documenting User Stories in Jira in anticipation of the development resources we were going to need.

The Story Map had now become the single source of truth for MVP Product Management and as progress was made, we could dig deeper on each iteration and prioritize objectives and maintain momentum.

Client-side User Flows, UI, & Iconography

The Myota MVP at this stage had 3 primary parts: OS-based file manager client, 3rd party cloud storage providers, and a web-based control server for configuration and analytics data.

We knew our OS-based user experience would need to look & feel fully integrated, but it also needed to emphasize the threshold of increased security provided by the product, and all while communicating the current state of storage, retrieval, and securing of data on an individual file and application level.

Working through the primary flows and testing the functionality with our early adopters to verify we were hitting our usability and experience targets, we turned our attention to mocking-up some future features for gauging desirability with users and exploring functionality.

Wireframing & Prototyping our way to Future Features

Industry Expert 1-on-1 Interviews

Some mid-fidelity wireframes helped the team get a hands-on feel for possible data visualizations and interactions they felt would be necessary.

Exploring higher fidelity concepts allowed us to get a sense of desirability from potential admins who manage or resell information security solutions similar to what our MVP would offer.

To ensure we were getting maximum feedback out of the small group of industry experts we engaged, we took a 3-pronged approach:

1. We began by asking potential admins what kind of features they’d consider a must for this type of product.
2. Then offering lo-fi wireframes we asked potential admins to tell us what functionality they anticipated behind the vague UI elements.
3. Lastly, reviewed mid-fidelity wires to get potential users’ response to some of our novel feature concepts.

With end users transferring & recovering GBs of data with the MVP, a backlog full of work-to-do, and the acquisition of new skillsets and leadership – Myota had arrived at a major milestone.

Prepared to take on new investors, upgrade dev infrastructure, and zero-in the most pragmatic partnerships & markets, the project had come from a great concept with lots of hidden risk & ambiguity to a fully ideated product with a full backlog and a single source truth. What started as a bunch of stickies was now well organized user stories documented in Jira & features prototyped and validated with users, experts, and stake holders.

Myota’s product offering continues to develop as the company progresses toward a remarkable future securing and managing data under ever more hostile environments full of ransomware attacks and data leaks.

For more about whether Myota can help you secure your data, visit https://www.myota.io/