The purpose of my workflow is to design solutions to my client’s problems. Actually, if you think about it, the problems are of my client’s clients.
In most cases, the problem to be solved is not obvious. It must be discovered. More often than not, the client is focused on one aspect of a complex problem, but has not figured out which part of the problem their product will solve for.
Building things before completely understanding what the problem is results in a product that has little to no value. For example, a business owner may think she needs a mobile application. I build the mobile application. A few months after finishing the project we still have no signups or downloads of the app. It turns out, she didn’t need a mobile app. Rather, she only needed to add a feature to her business’s website. This brings up another point which I get into more in a few paragraphs: understanding what your customer needs and is willing to pay for.
It is not only the client who may steer the ship in the wrong direction. In the past, I would try to sell solutions. “Buy a website. Buy a video. Buy an email marketing package.” I continued to run into the same problem over and over. I built products and provided services that did not produce a financial return on investment. In order to produce a return on investment (ROI) it requires a product or service that solves an economical problem in a business model. That means finding the answer to the question, “How do we spend less money, and increase sales?” The answer, is to streamline and automate as much of the business model as possible. This is a much different approach than selling a website, email, blog, video, and consulting package without ever knowing the specific intricacies of how a certain business exists in the world. I was selling solutions first, and worrying about the problems later.
Note: depending on where I am in the process of building, launching, or managing a product I will often determine the order in which the below items take place. Understanding each list item individually should enable you to develop a strategic road map that meets the needs of your project specifically.
Talk to the customer
Understanding what my customer needs is more important than building a product that fulfills my own desires. It produces more successful results as well. Ask your customers what they need. Really, just ask them. They will tell you if you have a conversation with them. Shoot them a text to setup a coffee meeting. Send them an email to setup a phone call. “Accidentally” run into them at their local coffee shop. Do whatever it takes to get out there and talk to your customers.
Especially if I am thinking of building a product or a new feature that requires a lot of time, I will first speak or get feedback from my customers. It may be difficult to see the bigger picture if this is your first time getting customer feedback, however, approach this step as if you were building a system. A process. Try not to think about it as speaking with one customer at a time. Rather, imagine how to setup a feedback system where your customers are always within reach and available to speak with in the future in the event you want a second round of feedback from them. They call this building a feedback loop.
Building minimum viable products (MVP)
I have been immersed in building startups that solve social problems. I spend a lot of time researching topics such as inequality, domestic violence, poverty, hunger, etc. A few weeks ago, I had an idea for a new mobile application. During a time I was reflecting on my research while sitting at Starbucks staring at the wall, an idea spark hit me. I sketched out the idea on paper, and designed a simple one page website to represent the idea. The paper and pencil sketch was the first version of a minimum viable product. It was more of a storyboard that included sketches of each important screen the app would have.
I used the sketch to show close friends the concept and ask them whether it was a good idea or if I was just crazy. Once I got approval from my inner circle, I designed the sketch using PhotoShop. Once I was happy with the PhotoShop design, I developed the design into a one page website using WordPress and Headway.
The developed on page website was the second iteration of my minimum viable product (MVP). Using the MVP, I can tell whether customers are interested in the product by measuring the amount of email signups. I did not put in all the work of developing an entire mobile application, but from the website it looks like the app is almost finished and ready for use.
Unpack business models
I like to unpack business models on a big whiteboard. Similar to the mindmapping process. I start by identifying how exactly the customer finds the product. That becomes the first bubble I draw on the mindmap. You may start at a different step in the overall business model, however, that is where I start. Next, I identify how the exchange of money for product happens. Who does the customer speak with? Are they able to purchase through a website? After the purchase is made, then what happens? Do they receive access to the product via email? Are they mailed something in snail mail? Do they receive a confirmation email? Then what happens? I continue through this process until I have the entire business model unpacked.
This allows me to discover opportunities to streamline and automate outdated processes with the new solution (product) I’m building. It becomes effortless to identify new ideas for bridging the gap between archaic end points.
Identify the problem
As I map out each step of the business model it allows me to make connections between seemingly unrelated ideas. These bridges are where the creation of new ideas exist. Unpacking the business model allows me to identify problems that were hidden deep in the bureaucracy of any organization. Is there a repetitive task that needs to be streamlined or automated? What can I create to remove the repetitive aspects of the task? Where does the user experience friction? How do I make the purchase experience more seamless for the customer?
I usually start the buyer persona development as early as possible. Please don’t be mistaken because I added it last to this list. Planning the workflow for a project can be a time consuming process if I know nothing about the intricate details of a customer. I want to know who exactly is going to use the solution I’m building. How old are they? Where do they live? How much money do they make? What is their occupation? Do they have kids? Husband or wife? Are they allowed to take phone calls during the day at their occupation? That last question is incredibly critical because if I was a business owner attempting to sell a product I would want to make sure the customer is actually permitted to answer the sales call at the time of day I called them. These little details add up to have monumental impact on the success rate of a product and its conversion rates. Here’s one of my posts that goes into great detail regarding buyer personas, examples from my clients, and a buyer persona canvas app that will save you a ton of time.
Hope this helps you understand my workflow, and helps you develop your own workflow. If you have any questions, or if you would like feedback on a project you’re working on please contact me anytime. Feel free to visit one of my accounts in the top navigation menu or connect with me on Twitter http://twitter.com/danieldalonzo
Thanks for your time!