Pyoneer Case Study

At the time I started at Pyoneer, the company was positioning its product as Design Thinking / Product Management Tool, whatever it meant. At the same time the only thing the tool was doing, was collecting customer feedback messages from different sources via integration like App Store, Google Play, email or simply with CSV import; and sorting all messages by Themes with underlying NLP technology (Mastercard, Paypal, Checkout, Billing -> Payment). There was an attempt to detect insights automatically (the site crashes on the checkout -> the payment is broken -> bug). There were also some other features, like changing the changing status of insight and detecting its importance.

I had to dive deep in tons of marketing materials, blog articles and sales presentations can link the Value Proposition with what the tool was doing, and they would not connect even on a vast stretch. Things were confusing, filled up with fancy terms that did not help to understand how and for whom the product can be useful. So the starting point was to clear up the company Mission statements and fix that core JTBD that we as a company would focus on.

Marketing materials with an unclear value proposition

It had to be easily understood not only by the outsiders — potential customers or investors but by our team in the first place. Having a vague, unclear Vision makes the teamwork very chaotic — everyone seems to be busy working on something significant, but it’s unclear where it is all leading. We have conducted market research and several brainstorming sessions to list our functionality and technical accomplishments, and what would be the simplest Product that could deliver real value to a business. What we have settled on was the Automating Customer feedback analytics. As simple as that, everyone could understand and relate to it and yet it was a painful enough problem that still was not solved in a holistic way. From our market research, we have found out that there are quite many attempts to solve this problem, but not a leading solution yet. Some Products did an excellent job on aggregating and allowing to work with customer feedback. Still, they were barely automating the process, those that used the AI technologies, required very complex setup and were mainly enterprise-oriented. So although the competition existed, there was still place for simple easy to get started the Product to do the job.

Old version of the Product

We have decided to put the NPS and Language Recognition technology as our core and through all our capacity into it. That meant that we were not stepping into the busy Product Management Market anymore and did not try to cover all other related jobs such as prioritization, product planning, visualizing roadmaps and retrospect upon team OKRs. It meant that we had to through away quite a bit of already existing Product functionality and completely re-think our roadmap. The decision was that from now on we do one thing — but try to do it well.

When the Vision started to get its definite shape, we needed to take action to, firstly, communicate it to the external world, and, secondly, develop a robust Product Strategy.

The rebranding was the solution for the first problem. It was a good time to through away all ambivalent legacy materials and communicate our new Values in clear, fresh, straightforward way. Changing the visual language was a sign of the mentality change. It certainly helped up to get some traction around the Product and start new conversations on the Sales side.

New brand materials with updated Company Mission

As for Product itself, we took a similar approach — the decision was instead of twigging and hacking the existing Product, that was covered with non-sense features like a Christmas tree, we just decided to do it from scratch. The options were either continuing with the agile way or making small changes to the existing Product or take a step backwards to re-create the entire thing. We decided on the latter. It would be too many little changes to get from point A to point B, that would cost as much more time in the end. It might sound quite radical, but it only meant that the frontend layer had to be re-written, thanks to well set up APIs it created very little work on the backed side, which said we could continue to develop and refine things based on the new strategy.

Draft of Product Architecture with roadmap remarks

On the other side, from the UX perspective, it meant a massive change, but it was necessary. We started with building consistent and scalable product architecture, that would accommodate the MVP functionality and allow natural expansion later. I started with the core user jobs, and mapping up primary user flows for each. After a few iterations, I came out with a simple product tree with 3 basic space-templates

1. Inbox (list of messages view) — sortable and filterable table with messages and, later, highlights and metadata about each. Space could be used as for all available signals, as well as messages within a group regardless of grouping option (Theme, Sources, Audience etc.)
2. Groups Board — a list of message groups with stats — Themes, Sources, Audience etc.

New Product Spaces

And secondary views for each flow

• Importing data
• Working with a particular message
• Filtering sorting messages to get quantity data
• Creating and editing a group
• etc.