What would you do if you had a software idea, how would you go about building it?
I used to think it was as easy as sitting down with a developer, giving them a 3-minute run down of the concept, and then sending them away to get coding.
As it turns out, I was about 10 steps ahead of myself.
The concept for FlypChart was crystal clear in my head, but every time I tried to explain it to someone else I got a different reaction. Somehow I needed to create a universal understanding for this thing, and help others tap into the vision I had for the software.
And it wasn’t just about having something a coder could understand. I needed genuine, actionable feedback on the concept otherwise it would never get built – so this “product definition” needed to be in a format that anyone could quickly recognize and appreciate.
It soon became clear that I needed a prototype. (More about that in a later blog post)
But to get a nice-looking prototype I needed a designer, and to get a designer I needed a well-defined definition of what the product was going to be… Otherwise they’d be shooting in the dark.
So that’s what I went about doing.
Defining the product
The market research we did helped me form a much better understanding of where the product would fit in amongst a sea of other digital marketing software. And as time goes on, and I speak to more people, that definition is becoming more refined and specific.
There were some key questions I needed to answer about the “Product”, so that I could put together a briefing document for any future designer or developer.
- Based on the problem the software is trying to solve, how does it need to function?
- How do people currently do what it is we are trying to replace, and how can we make the experience an easy transition?
- Where in the market is the opportunity and what are these people willing to pay?
- What brand accurately depicts our vision, the market, and our ideal customers?
Let’s take a closer look at how we answered each of these questions:
1. Functioning to solve a problem
The primary problem FlypChart is trying to solve is specifically related to “tool overload” and the inefficiencies associated with running marketing campaigns across multiple disparate platforms.
A typical digital marketer has at least 5 browser tabs open when they are preparing a marketing campaign. Their calendar, a spreadsheet, email marketing software, a social scheduling tool, webinar platform, a communication tool and a project management tool.
This was our starting point… Understanding this workflow would allow us to define a product that could aim to bring these things together as one.
The first thing to consider was access.
When I say “access”, I’m referring to how a user accesses the software.
Will it be on their laptop, a desktop computer or their smart phone?
The reason we needed to figure this out was because it would greatly influence how we built the MVP.
Apart from asking people how they would usually run a campaign, we also took a look at other software our ideal customers were using, to pinpoint how they were providing access to their users.
We soon discovered that while a mobile app would be cool, it definitely wasn’t essential, because most people were building campaigns on a computer. And because they were using so many different online tools to build these campaigns, they were already familiar with accessing applications via the web, so a desktop app seemed just as unecessary.
Soon enough we made the conclusion that a web app was the most appropriate access point for this software.
So what does the software actually need to do in order to solve this problem?
This is when we started to figure out the exact features or functions the app would need, in order to help our users effectively execute on marketing campaigns.
I had this list somewhere buried in my subconscious, but writing it down on paper certainly clarified things for me.
The primary question I had to answer at this stage was:
What does someone have to do, step-by-step, to set up and run a digital marketing campaign through to completion?
As you can imagine, that is a fairly broad question that has different meanings for many different people. Initially it felt like drinking from a fire hose.
Some people were talking about webinars, others were talking about quarterly live events, some were talking about product launches, and then others referred to a campaign as the repetitive content promotion process associated with publishing a blog post. Somewhere amongst all of this information were some common elements that would make it onto our functions list.
Eventually we landed on a list of “content types” that are used during typical campaigns, you can see them in the image below:
As well as providing a campaign solution for marketers, the tool also needed to be user friendly, provide adequate live support, and enable me and my team some sort of admin functionality.
All of these things made it onto the first “wishlist” of product functions that you can see in the screenshot below:
After we had an idea about how the product would function, the next step was to identify what other tools we would need to integrate with to make it all happen.
FlypChart at its core isn’t trying to replace other social media, webinar and email tools. Instead it’s trying to complement these other tools and enable marketers to deliver more effective campaigns time and time again from one place.
The “integrations”, especially those with established email marketing platforms, is one of the primary differentiators for the software. However, it also posed one of our biggest challenges.
API tool integrations are complex, they’re all different, and they require fairly regular maintenance. This had the potential to bloat development costs and derail the project all together. (It’s probably why no one else has done this yet)
The harsh reality is that ALL the tools that everyone wants integrated won’t be possible in the first release of the software. So we had some choices to make.
First, we needed a list of all the “potential” tool integrations.
What email software did our ideal customers use? What webinar software? Social networks? Ad platforms? And so on.
I literally just brainstormed every tool I knew about for each category, did some research, and then tested my assumptions with people on live phone calls. To give you an idea of the challenge we were dealing with, there are over 10 email marketing softwares alone that at least some of the target audience use.
Once we had this list, we then needed to figure out if it was even possible to integrate with each of the tools. This was a nervous discovery period for me, because if it turned out that some of the most popular tools couldn’t be integrated, it might’ve spelt the end of the project.
Most established software products have a public API and supporting information about how to integrate with their software. For example, Infusionsoft have a whole portal for developer information.
But of course, we needed a developer to research deep into this information for every single potential tool integration… Just to see if it was possible.
Once we had confirmation that these tools could be integrated in the way we wanted them to, it became a decision of “what would make it into the first release”.
At this very moment I don’t know the answer to that question. But if you’d like to have your say as to what gets built into the first release, we have a quick product survey you can fill in here.
2. Creating an easy transition
One thing we had to remember while building out this product definition was that inevitably we were trying to replace, or intertwine, with other products already out there in the market.
We had to fit into whatever someone’s current workflow was with ease, because the biggest deterrent to trying out a new tool is usually the effort it takes to get set up and going.
The two key components that would make for an easy user transition, were the aesthetics (how it looked) and the user interface/experience (how it worked).
Aesthetics and user experience
In order to create a tool that would seamlessly slip into a digital marketers daily workflow, I drew inspiration from three places:
- My own experience with running digital marketing campaigns and observing others do the same
- Asking experts and potential users exactly how they ran campaigns, what they liked and what they didn’t like about their current workflow
- Actually using the other tools that we were trying to replace and integrate with, to see how they were designed. Everything from email software such as Mailchimp, through to communication platforms such as Slack, and project management tools like Trello
The goal from all of this research and discovery was to create a visual representation of the tool that would be different enough, so people were excited. But still similar to something they had experienced in the past, so the jump across didn’t feel too big.
Once it came to the stage where I was discussing design elements with a UX designer, I used some of these other tools as reference points. I provided specific feedback on what I liked, and what I didn’t particularly like about each. This helped shape the end output which was the FlypChart prototype.
Here are a couple of other tools that I used in this process:
3. Finding the true market opportunity
Where EXACTLY was the opportunity in the market? When is the problem that we are solving a big enough roadblock for people to pay for a solution?
I was looking for a way to determine product/market fit.
The questions were simple, but the answers were not…
After doing the market research we were left with one primary problem. But that problem was broken into 3 secondary problems, for 3 separate target customers. (Read more about them in the Customer section of this article)
There is no way we could effectively launch an MVP within budget, targeting 3 different groups, and solving 3 somewhat different problems.
We had some choices and tradeoffs to make.
The three questions I needed to answer in order to determine product-market fit were:
- Which group has the will and capacity to buy the software right now?
- What is the number one problem that we can solve for them?
- How can we solve that within budget?
I’ll be straight with you, the answer to these questions is in no way linear, or black and white. It’s muddied and confusing.
At the time of writing this blog post I have spoken to over 40 people on Skype and sent about 300 research-driven emails, and only now am I starting to see some common themes that will influence the inevitable positioning of this product.
From all of that research, and the ads that we have been running to the landing page, I am trying to funnel as many people as I can into taking the product survey.
This survey is your opportunity to have a say and influence the direction of FlypChart. It is the primary input we will use to decide on the MVP functions, first tool integrations and pricing of the software.
4. Building a brand
I wish I could say that there was a perfect, step-by-step process I went through to define the FlypChart brand… But there wasn’t.
I referred to the concept as “MarCal” for most of the secondary research phase, and had that name printed on our documentation. I knew that wasn’t going to be it, but it did the job as a placeholder.
It seems silly to obsess over a name, or a brand, before you even have anything built. But it’s important. The way you represent your brand in the market, the way people perceive your business, the way it sticks in their subconscious – that all matters a LOT.
My understanding of what a brand is comes down to a few key elements:
- The logo
- The colors
- The story
- The values
The strength of your brand is about how consistent you make these four elements in the marketplace. Across social media channels, on your website, and in the mind of your ideal customers. It’s what you stand for and how other people perceive that. That’s your brand.
So the “Branding” is still a work in progress. Sure we have a logo and a name, but whether or not we effectively execute on building that brand, and scaling it consistently is another question.
Note: I weeded through over 40 different names and 150 different potential logo designs before going with what we have now. It was messy, and there was a lot of back and forth with designers. But we made it 🙂
I mentioned in the introduction that we needed a prototype… Something that anyone could look at, feel and experience in order to understand the vision of the software.
But before we could get that prototype designed with any sort of confidence, the product needed to be clearly defined.
How would it function? Who would be using it? What’s their workflow? How do we fit into that workflow? How do we depict our vision in a name and logo?
The answers to these questions formed a pivotal part in the creation of this prototype and the development of FlypChart as a business… It wasn’t an just idea anymore.