Yesflow CEO Scott Millwood explains how tech startups can use codeless mockups to build customer loyalty and user engagement.
This post is part of Designli’s “Entrepreneurial Insights” series – where we profile successful entrepreneurs, discuss topics that are critical to business-building, and pass those insights to today’s founders and business leaders.
If Scott Millwood says your tech startup should use prototypes as a sales tool, you better listen.
When it comes to software sales and marketing, Millwood boasts quite the pedigree. During his eight-year tenure as Senior Vice President at Datastream, he helped grow the company’s revenue from $15M to over $120M. Afterward, he went on to bootstrap his own CRM consulting firm, which he later sold to Hitachi Solutions in 2014. Now, Millwood is the CEO of Yesflow, a Greenville-based software company he founded in 2018 to help people utilize a digital assistant to get enterprise CRM work done on any device from anywhere.
After just two years, Yesflow’s AI-powered digital assistant is fully functional and live in the App Store. According to Millwood, prototypes played a critical role in this success. “Prototypes are central to the story of Yesflow,” he says. “They are integral to how we got to where we are today.”
In the software development world, a “prototype” is an early model of an app – usually a series of sketches, wireframes, and mockups – that companies use to test features and product ideas before sinking time and money into development. Prototypes are often used as a mechanism of getting user feedback early and quickly so that product teams can triage revisions according to priority.
Although prototypes have indeed helped Millwood save significant time and money on development, they have played an even more significant role in his sales efforts – especially in the early days when there was no live, working product to showcase. “We had to have something to go talk to prospects about and show them where we were going,” he says. “With a prototype, I could at least get out in the market talking about and showing the ‘chicken sandwich’ even though we hadn’t built the ‘restaurant’ for the chicken sandwich to be produced in.”
According to Millwood, the goal was to learn what people actually wanted and to get people invested in the product before they had even tried the real thing. And he realized the way to do that was by involving users in the “journey” of designing and improving the product. “Prototyping is absolutely a part of an early stage marketing and selling strategy,” he states. “It’s not just about getting your product to market. It’s about getting customer feedback and getting them engaged and bought into the solution.”
Before they had a working product, Millwood and his team hosted several half-day workshops at the office where they had a group of customers go through product prototypes and use case scenarios for the first release of Yesflow. Millwood wrote a list of customer use cases and product features on a whiteboard and had everyone assign relative value to them using big yellow sticky notes. Fourteen months later, when the new release finally went live, those customers were as eager and committed to the product as ever. “The workshop certainly helped us build a better product,” Millwood says, “but just as importantly, it kept our customers engaged by making them feel like they were part of the process.”
This type of feedback-centered workshop has been equally valuable for Yesflow’s product team because it has forced them to take off their “techie hats” and think like the customer. “Instead of thinking about how to connect to the data, or what the architecture behind the system is going to look like, it makes us think through what the user is going to feel,” Millwood explains. “And through this lens of empathy, we can see where in the product there is true value, and where there is just noise.”
Entrepreneurs, especially those with a background in software development, often come at the world from a technology-first perspective. While this is certainly an important area to address in guiding the creation of a product, Millwood warns builders of becoming blindsided by back-end considerations. “I’ve seen situations where developers build everything behind the scenes perfectly, but nobody cares because they haven’t proven anything of value to the customer,” he says. “They have just proven that the technology works – that’s it.”
Millwood notes that for Yesflow, prototyping was the right place to start because the team wanted to gauge users’ reactions to the product concept and determine if it had value. Of course, Millwood had no intention of tricking people into thinking the product existed when that was not the case. In fact, he says his team would always be very clear in explaining that what they were showing was simply a representation of the product – the “pretty screens” that a back-end framework would be built to support.
However, as Millwood will tell you, it can be hard to test a product concept when that concept is not readily apparent from just those “pretty screens” alone. As an AI-powered digital assistant that relies on speech recognition and natural language processing (NLP) to render a result on the front-end, Yesflow encountered this problem regularly. Users were never able to understand what Yesflow was about from just seeing a few screens linked together in a prototype.
To overcome this challenge, Millwood would start each demo by showing similar technologies – like Siri, Alexa, and Google Assistant – that illustrated how the Yesflow technology would work. Then, he would show a prototype of the Yesflow front-end to illustrate how the digital assistant app would work when it was connected to the customer’s enterprise CRM. “We would tell a parallel story,” he explains. “That seemed to help users ‘get it.’”
Another challenge Millwood faced in creating a prototype was representing how data moved between users. In the live product, when a user clicks the “big orange button,” a voice box appears that records the user’s speech and translates that speech to text. The app then sends the message to the intended recipient, who can respond through a similar mechanism. But in a prototype, there is no easy way to depict this back-and-forth interplay between users. “To simulate that experience,” Millwood explains, “we designed a series of mock-ups that would show a pretend voice capture on the screen, and a pretend text output.” He would give each user a different set of screens – each with a distinct text output – and guide them through a “role play” in which they would pretend to record their voice and communicate with each other through the prototype.
Millwood does admit that after a few months, this prototype “ran out of gas.” The team had determined the right user flows, interactions, and interface designs. And they had gotten user buy-in. The most important test, however, still remained: did the technology work? “The challenge in a voice-based conversational assistant,” Millwood states, “is that there is no MVP – that is, minimum viable product. It either works or it doesn’t work. There is no in-between.” He realized it was time to push forward on deep technical development.
For Yesflow, prototyping and development ran in parallel for six months. “It’s important for people to remember that prototyping and development aren’t sequential,” Millwood specifies. They are cyclical processes that should always be running in parallel, with prototype testing influencing how the architecture should be built so that it best aligns with user interests. “It’s once you figure this out,” Millwood concludes, “that you can make the magic you envision come to life.”
Designli leads clients through the design and development of complex digital products. Ready to bring a mobile app or web-app to life? We’re ready to help.
Return to main page