Writing

Recent thoughts and gifs on the blog…

Don’t build it all. Picking a Platform.

Often a client’s first knee jerk reaction is to want to build their product on as many platforms as possible. “Our customers and our admins need to be able to access their account online and on a mobile app and maybe on a desktop program.”

And then when I suggest maybe only doing only one of those…they get…kinda hostile.

They think that I don’t believe in this big idea. Or I don’t want to help all their users. But, this isn’t it at all! By telling you no, what I really mean is that I want you to be successful! And successful when you’re a fledgling startup means starting small and focused.

I totally get it. You don’t want to miss out on an opportunity to connect with a potential user and their potential money just because they can’t access your product easily, but trying to build out multiple code bases without any initial customers or validation is a very. costly. mistake.

The first thing you should code up when starting a new product is an MVP…or a MINIMUM. viable product. Does building your first product for multiple users to access online, on phones, on tablets and on desktops sound very minimal? Nope.

So what should you do? Which should you pick? How do you even do that?

Don’t worry! I can take a quick look at a couple of different aspects to decide which platform is best to start with.

First let’s look at what kinds of tasks your product will contain.

Will your users need to type in a lot of text?
- This will mean your product needs to run on something that has a real keyboard. (Web or Computer Program)
Will your users need access to a camera or video? What kind of photos or video are your users needing?
- Is it candids like Snapchat (App)
- Or is it more meetings like Zoom (Web)
Do we need the user’s location? How accurate does this need to be?
- If we’re offering some sort of running, fitness, or habits product we’ll need an app that can offer that hyper detailed data.
- If we just need to know nearby items (think Yelp) then maybe typing in our zipcode on a website works.
Does this product need a really high level of visual polish or performance?
- Depending on its speed and visual needs, maybe don’t consider a hybrid app or web app for starting off.

Then look at where these kinds of tasks will be done.

Are they needing to do these tasks while out and about? (Phone or Tablet App)
How about offline/no service areas (Native Apps)
Is this daytime, office work? (Web Browser or Computer Program)
Is this an evening, couch activity? (Phone App / Responsive Web)

Who will be using this product?

Kids? – Most kids use inexpensive tablets
Office staff? Maybe custom software or web service or inexpensive android tablets
Gen Z? New Moms? Senior Men? – Each demographic migrates to a certain kind of device depending on finances, habits, and age.

Now of course, people have varying habits and not every single user you talk to will say that they want to access your product in the same place. (In fact most users will say that they want more choice – even if their actual habits show them using the same devices over and over.)

So what you’re doing with this exercise is deciding which platform has the most logical overlap for all of these questions/answers for your target user.

Sidenote: Pretty much ALL of my advice involves touching base with your users and their needs. Make sure you genuinely understand your “core” user and remain focused on them. If you’re not sure how to do that just yet, check out my article on “Knowing your Users”.

Okay. I know more about where my users are and what this product might need, now what?

Now, pick ONE PLATFORM for your MVP.

Only one? Really? But…but…I can’t! I need them all. This way I don’t miss out and ALL of my customers are always happy. Please can’t we just build for web and mobile and desktop and tablet?

Nope. For your MVP, building for one platform will help you in a myriad of ways.

It helps save development time and money
It reduces churn when you need to change or tweak features
It even allows you to focus your marketing for that initial launch only in places and with groups that will use the platform you’re on.

These sound like good things right? Not doing ALL the things IS a good thing. I promise.

Also, just because you launch with one platform doesn’t mean you’re barred from expanding for all time. If you have amazing demand, then this means you’ll also have more money and information from users to know where to go next (build that Android app! Add that desktop version!)

If you over build and were *gasp* maybe a teeny bit wrong about your users, then you have a big ol’ technical piece that is getting dusty, is underused, and is likely still costing your financial resources to maintain.

Don’t be this creepy, empty castle subdivision in Turkey.

If you feel pretty confident about knowing what your user’s want and where they are but still need help determining the technical solutions, I’m happy to help. Send me an email (from an app OR a website! ? )

What’s in a name?

You have the idea. You’ve asked others about the idea. You have plans to build the idea. But…in order to start writing code, buying URLs, designing branding, doing your social media thang….you need a name.

Easy. I’ll just come up with a name. No. Big. Deal.

A few hours later, you have a name, you love it. You think it’s pretty clever. You’ve decided to name your idea baby: Xymr (You know, like simmer but with zest”). The product is a recipe app for dogs (obviously).

But when you email about Xymr to others their eyes twitch, they ask…so what does “Ex-eye-m-ar” do? Or you recommend Xymr to a friend at the dogpark and they google “Zimmer” and find nothing. Or they do get it right, and oh hey, it looks like the first entry for Xymr goes to…a…porn site. Wait, you never googled your own company name? Oh man.

See where I’m going here? A good name for your product or company isn’t necessarily trendy or cool but one that works. Everytime. It needs to work visually, aurally, and on the internet. Unique but not tooooo unique.

Easy right?

There are some basic rules to try to follow when coming up with a product name and while you don’t have to follow all of them, it’s important to weight the importance to your audience of each.

Spelling. You can be creative but not too creative (leave the vowels please!). People will hear about your product and search for it. Make sure what they search will bring them to your product.
Being unique. Also known as Google juice. If someone googles your product, are you going to be front and center? Or 9 pages back. Don’t name your company “Googl”. Don’t name your cooking product “Kitchen” or “Recipe”. It’s a losing battle with the SEO giants. Your user isn’t going to hunt for you, and if they can’t get to your product with one or two obvious search terms your name needs to be better.
Competitors. Don’t be too similar to competitors. If you name your company Zimmer and your competitor is named Simmer, you might be losing half your interested audience through a mistaken search. Don’t make users hunt for you.

Now as an aside, you might ask – what about Spotify, what about rrreally unique names? Brand new words? You CAN do this, but again it needs to be easy to hear, easy to spell, easy to search, and easy to remember.

Okay, so I have what I shouldn’t do. Now, how do I go about finding a GOOD name? What if I can only come up with derivative garbage? Work Corp. Synergy Labs, Best Business.

First I like to start by setting the mood for brainstorming ideas. Relax. Be prepared to be silly. Have a beer or light some candles. Get hopped up on sugary donuts. Ready?

First, write down adjectives you’d like people to think about when they think of your product.
Then, write down words related to what your product does.
Do you have a giant list of words now?

Here’s an example. For our dog recipe app, I’ll write down some adjectives: Dog, Pet, Puppy, Pup, Food, Nourish, Meal, Healthy, Delicious, Fun, Homemade, Authentic, Cook, Prepare, Create, Craft, Kitchen, Stir

Now, let’s make that list bigger and more interesting. See if there are any words that are similar but we didn’t think of.
Go to thesaurus.com and turn those 20 words into 100 similar words.
Go to Google translate and turn those words into other languages. (latin, greek, sanskrit, portugese, anything sound cool here?)
Stretch your brainstorming even further. I personally love this site: https://onym.co/
Now you have a biiiiiiiig list of words.

You can remove ones you don’t super like or aren’t working for you. Be brutal, slash it down to just the words that make you excited for your business.

Here are some additional words we found: Pooch, Fido, Chow, Fare, Grub, Snack, Fresh, Fit, Hearty, Make, Plan, Mix, Victus, Canis, Hundo.

Next step. Go to Bustaname.com and put in your list to start making combos. Tinker with the word combos (first vs last), suffixes, prefixes.(Sidenote: I know this site is ugly, but it is powerful. There will be a lot of garbage in there, but also some gems. Sort for your gold!)
You can also think about prefixes and suffixes -ly, -fy -ist. Or group combos +studio +labs + craft +bits +team.

For this exercise – Bustaname suggested pupmeal but I like the idea of MealPup – a short, quick, fun meal for your puppy, puppers, pupperino.

Now even though Bustaname has done a rudimentary url search, go ahead and google search them, social media search them, and url search them. Few competitors? Available handles? Friends can successfully type it in or pronounce it? You have a name! Time to start plastering that baby everywhere.

Talk to your Users

There are many, many steps when it comes to building a product and many can be unique to the situation, but there is always one task that is the same for all of these. No matter what. No matter when.

And that is sharing your idea, prototype, or product with others – also known as user testing or user research.

But…here is what I often hear from clients when I talk about this step:

But I don’t want anyone to steal my idea when I talk about it to them.
But I don’t need to test with users – I know exactly what they want.
But I don’t have time to test with users, we have to be first to market. I need to start building now.
But I don’t have the budget for fancy user testing.
But I don’t know where to find people to be my testers.

This. is. bullshit. When you tell me the above, what you’re really are saying is: “I don’t want anyone to challenge my perfect idea-baby.” and/or “I don’t want to put in the time to do this – I just want to do the fun part – which is locking myself in a room and coding up a monument to my own genius”

Showing or talking about your app is scary. You’re making yourself vulnerable. You’re allowing others to poke holes in your idea, your design, your code. But guess what? It makes not only you, but also your product stronger and ultimately more succcessful. I’ve never ever had a client say “I wish we hadn’t spent time on that” or “The user feedback was useless”.

So first, we’re going to debunk these common excuses. Then we’re going to cover how to user test – now that you have no excuses.

But I don’t want anyone to steal my idea when I talk about it to them.

Having an idea isn’t special. I have dozens of app ideas each week (pretty much all of them are dumb). It’s the building of the idea and making sure that it’s problem is a common/compelling one. How do you know if others have this same problem? By asking them. How do you know if this idea is dumb? By asking people.

But I don’t need to test with users – I know exactly what they want.

Really? You and every one of your users is exactly the same? And there are enough of you to make a profit? Just humor me and talk to a few other people who would be interested. Learn a bit more. You might be surprised about how similar, yet different your audience can be.

But I don’t have time to test with users, we have to be first to market.

It doesn’t matter if you’re first if your product sucks. Many of the most popular products out there weren’t first, but they did take the time to get it right. Building then changing, then building, then changing after you’ve launched is going to be painful and expensive. User testing doesn’t have to take weeks, it can take as little as 3-5 coffee sessions and it will save you hours in churn. (It might even save you from building a failed product to begin with).

But I don’t have the budget for fancy user testing.

You don’t need expensive or fancy tools. Whip out some Google Surveys, take some old fashioned notes and hit the pavement. User testing is genuine sweat equity – no expensive developer required. Honestly, I encourage most of our clients to do the user testing themselves, with us as an advisor. If you’re not elbow-deep in feedback, how will you truly understand your own audience? This is not something you should outsource and doing it yourself = cheap.

But I don’t know where to find people to be my testers.

Um…if you don’t know of anyone who would be interested in this product, how are you going to find customers once it’s built? ? ? ?

But okay, maybe the problem goes more like this: “I know my user’s are construction workers – but how do I reach those people directly?”

The internet is a wonderful and magical place my friend. Check out industry forums for your kind of user. Check out Facebook groups, Twitter hashtags, LinkedIn groups, local meetups, post a question on Quora, etc. You can even go next-level vulnerable and go to a REAL LIVE place with these kinds of people and talk to them there – home depot, the park, a bar!

The worst thing that could happen is that you ask your question and you get crickets or someone saying no thanks. The best is that you have awesome, long, meaningful conversations with your potential users and come away with a bit more insight.

So I’m convinced. Now how do I do this thing?

There is no “perfect” path for user testing and there are a few different ways to arrive at the same result. Don’t feel overwhelmed. Even doing one of these types of testing will set you far ahead of your competitors.

Early Days – Idea Validation through User Discussion

What: Validate that your idea/problem area is even good/common. This is when you’ll decide if this idea has legs. Are people willing to pay for this product? Are there enough people to make that payment worthwhile? We prefer at this stage to start firming up the idea with a Lean Canvas exercise.

How: Talk in person to 10 – 20 potential users. This is a casual conversation, where you’re mostly listening and saying “tell me more…”

Ask them general questions like the ones below. The questions below came from this excellent resource.

What’s your relationship like with [topic … e.g. money, fitness, etc]
How do you currently go about [problem / task]?
How much time do you typically spend on [problem / task]?
Tell me about the last time you tried to [problem / task]?
What do you like about how you currently [problem / task]?
What is the biggest pain point related to [problem / task]?
Why do you keep doing [problem / task] … why is it important to you?
What type of work arounds have you cerated to help you with this?
What’s the hardest part about [problem / task]?
What are you currently doing to make this [problem / task] easier?
How does this [problem / task] impact other areas of your life / work?
What other products or tools have you tried out?
Have you paid for any of these other products or tools?
How did you hear about these other products or tools?
What do you like or dislike about these other products or tools?
Are you looking for a solution or alternative for [problem / task]?

Who: Find interview subjects through Facebook Groups, Meetups, Social Media (Instagram/Twitter), Family/Friends. Ask every single interviewee “Is there another person you think I could talk with who also potentially has this problem / could use a tool like this” Grow your pool. You’ll use this pool continually as you develop your product.

The Specifics – As Needed Polls

What: When you find yourself saying “I don’t know” or “I’m not sure” it’s time to ask your users a few targeted questions. Further refine fuzzy areas with this “one-weird-trick+.

How: Send short surveys to 50 – 300 people. Distill some recurring questions from in person interviews into 3-6 short questions. Set this up using Typeform or Google Surveys. Incentivize with gift cards / stickers / high fives.

Who: Email the link to your survey out to your interview list. Post the link on channels from above (social, family, network). Potentially look at services that offer curated audiences like Survey Monkey or Usertesting.com.

Prototype Time – Talking about the actual product

What: You’re ready to have users actually use your product – not just talk about it abstractly. While you’ve nailed down the big picture with previous user research – this is the “testing” part of the game. This can be done using a drawing of your product, or a design, or a rough coded prototype. User testing at this stage is making sure you have included the right features, organized in the right way.

How: Sit down with 5-10 people and watch then use a version of your product. This doesn’t need to be coded. In fact I strongly encourage you to slap together some design prototypes first before you’re attached to your beautiful, perfect, thorough code. Create design prototypes with a program of your choice: Balsamiq, Invision, Figma, Powerpoint/Keynote.

Allow for a user to generally explore your product, discuss their thoughts. Then ask a user to complete some common tasks for your product.

Big note: DO NOT SHOW THEM HOW TO USE IT. Use all of your willpower to remain impartial. Allow them to potentially flounder, get confused, or frustrated while clicking through. This is the point of user testing. It will be okay. Watching someone struggle in the prototype phase allows you to make changes to prevent all of your real customers from feeling this same pain. You will not be there in real life situations to jump in and hold their hand, so don’t do that here either.

Record these sessions with a tool: Zoom, Lookback, or Maze. This allows you to revisit areas later and see exactly what the user did while talking. Take notes of “moments of interest” to review and improve upon later.

Who: These should be your target users – your ideal customers. Focus on getting the UI/UX of the product right with the demographic that most closely resembles who this is for. One note about these users. Since they are looking at an actual object they will be tempted to suggest improvements, new features, etc. Use them to discover faults in the interface, but be wary of solutions they recommend – remain focused on what features set best fits your MVP size.

That’s It! You can do it! Please do it!

At the end of the day, it takes time to test your product with users. It takes confidence to approach others and ask for their time too. It takes bravery to put something that isn’t quite formed in from of others and ask for their opinions and it takes patience to sift through the feedback and discern what nuggets could make your product and ideas stronger.

The results, however, are so, so, so worth it. You’d be surprised how supportive and helpful others can be when it comes to building something new and it might even set you on a path to a product that could be more successful than your wildest dreams.

If you ever need a potential user, a pep talk, or some guidance, feel free to reach out. I’m happy to help you build the next big thing (or next tiny thing).

Design for Fat Fingers

Have you ever had this happen when using your phone?

You typed in a ton of things on a page and then go to tap the submit button and your finger accidentally hits another button or link nearby? Or you weren’t able to type in the fields to begin with because you couldn’t get the cursor to move to them?

Screens these days are getting large and we can technically show a ton of things on there…but the thing is…our fingers are the same size they’ve always been (and not all of us have tiny hands like Donny T.).

A rookie issue when getting started with mobile design is making your touch areas too small or crowding too many things in one spot. (You can infinitely scroll, which means you have infinite space so chiilllllll and space that stuff out PLZ!)

Making things hard to tap makes users frustrated, and when they’re frustrated, they don’t return. BYE YOU GIANT HAND PEOPLE! I DIDN’T WANT YOU SHOPPING ON MY APP ANYWAYS. (That’s probably not what you were going for, but that’s what they think.)

So what SHOULD you be doing when designing buttons for mobile apps?

Luckily for you, you don’t have to go around measuring the finger tips of all of your potential users. Apple and Android have determined the optimal tap targets for you.

Apple’s Human Interface Guidelines recommend a minimum 44 x 44 px area while Android recommends 48 x 48 dp* when designing buttons for mobile apps.
(Let’s not go into the px vs dp discussion today but here is some reading)

Now that’s a good starting point but those are MINIMUM requirements. Actually the average human finger pad is 10–14mm and the average fingertip is 8–10mm, which mean you should be shooting for more like a 57px touch target. This is also backed up by tons of research. Check out Fitt’s Law if you want a deep dive.

That’s pretty big. Is my screen just going to be giant buttons?

Don’t worry! While it is good to have a decent button size not only for tapping but also for legibility/accessibility, you don’t always have to give that much visual weight. You just need that much spacing around your tap area so that there is no overlap with another actionable item.

Image courtesy of Material Design Documentation

When starting your mobile design make sure to set up sufficient padding around all of your buttons using the specs above for the tap areas.

Happy tapping!

Sunk Cost Fallacy: Don’t do it.

So what happened?!? What did you do with all the research? Did you make the feature list?

We did take a few more steps post-market research.

First, with all of the info we now had from talking with ACTUAL USERS, we redefined our audience size and attributes in our TAM. And discovered that even though we were now focusing on two audiences (meetup organizers and conference organizers) we needed to further segment them into novice organizers and smaller conferences – which made our target audience much smaller.

Second, I listed out all the features needed to make the platform appealing to each audience. Then I took away anything that might not be quintessentially necessary. This list was still really long.

Let’s look at those two numbers:

Tiny audience
Giant feature list

Wait a minute…those should be flipped for a successful business, right?

This is the part of the process where you start making mental excuses even though your gut and rational brain are pointing elsewhere.

“I mean…it could work….we already put in a lot of time…people said they liked it…we can just charge less till we get more users…maybe we don’t need to target both audiences…man, we have this cool name already…everyone is going to ask what happened after our meetings…let’s just build it and see.”

And off you go to the wonderful graveyard of failed startups, because you couldn’t bear to kill you idea-baby during the research and validation stage.

It’s okay to admit that some ideas aren’t the right fit. It’s totally okay, even if you’ve put a lot of time into it.

Sunk cost fallacy is real y’all. Don’t be a part of it.

So off we go back to the drawing board, looking for a concept where the numbers make more sense and the build-out to MVP isn’t months long.

Sifting your User Research

So last we left you we were meeting with every meetup or conference organizer in the Metro-Nashville area. And then I emailed some in San Francisco for good measure.

When we’d meet, I had a giant list of questions that I’d generally attempt to cover during our chat. If we veered off into an uncharted area, no problem, but I typically tried to cover some of the same topics with each and every person I spoke with so that later I could compare and contrast responses. After each meeting, I’d “brain dump” everything we talked about into a text document. At the end of this I had over 20 pages of “notes” from organizers here in Nashville.

Welcome to Jennifer’s crash course in user research….

Did everyone say the same thing? Nope.
Did everyone have exactly the same issues? Nope.
Did you really expect every single person, to have the exact same needs? Well, no…but that would definitely have made this easier.

So how do I take all of this broad feedback and use it to come up with meaningful answers?

First I looked for trends…

What is something I heard from more than 3 or 4 people? Something that kept coming up without my asking or prompting?
What was the response when broadly outlining my idea? Tepid, interested? People will rarely, if ever, ACTUALLY tell you they don’t like your idea. They’ll just…kind of nod and make noncommittal statements about the idea instead of discussing how they, themselves would use it.

Now what are the trends amongst the people who offered similar suggestions or had similar responses?

Is it one specific kind of person or kind of meetup/conference?
Are issues noticeably split amongst different groups?
Are these suggestions/trends actionable, solveable, and from large enough demographics?

I discovered that those who, in a previous life, held a job that required them to be more social didn’t have as hard of a time going out there, hitting the pavement, and offering the right information to potential sponsors. I also noticed that organizers who had been doing this for a while succeeded through trial and error, or through helping with other local efforts like tech conferences where more experienced people gave advice.

All of a sudden our market for organizers who needed help with how to ask for sponsorship was smaller. It was looking like just newbies and those whose core competency was more solely focused on code versus people .

But, I DID have one piece of feedback that came up over and over from this more experienced group – “Once we’ve used up our personal connections, we don’t know who specifically to ask to grow our sponsorship” …not what to ask, or how to ask but WHO.

This was different from our initial assumption. (And why you do this process to begin with). And this isn’t feedback that we can easily solve with a simple solution. Which makes sense—usually the hardest problems are the most prickly. After some internal discussion we did determine that there were a few potential ways to tackle the “who to talk to” problem but none of them are super easy.

So now what?

We have to ask ourselves, can our potential product not only provide help to those with the “how to ask” problem (early stage meetup organizers), but begin to seed data and insights for those organizer-pros who have trouble with the “who to ask” part (veteran meetup organizers and larger conferences). Will our actual “value” be on the back end of the product and not where we initially thought?

In assessing your own user research ask yourself:

Are there still problems I can solve?
Can we still reach users with these pain points?
Is this still profitable? (Are there enough users with this pain point, is the solution reasonable to build, and will those users pay for it?)

For us, it’s time to go back to the business model and adjust our numbers. If not as many people are within our initial demo or willing to pay for the proposal product, can we get enough users in there to build data for a sponsorship leads product which seems more valuable to experienced organizers?

Next steps? We’ll attempt to broadly scope and estimate features for supporting the two types of users in order the reach profitability instead of just one. We’ll need to talk with organizers again now that we have firmer features in mind. And we should put some infrastructure out there to test the interest beyond Nashville (Product Hunt, Beta List, etc).

Testing the Waters – A New Product Idea

So you know how we were trying to “magic” an amazing idea last month? We made lists. We read books. We drew on the white board a lot. We looked at everything from Product Hunt, Beta List, and YCombinator. I even scrolled way back in the @BoredElonMusk Twitter handle (There are some great product ideas in there…that we’re not interested in building).

Well after weeks of being super negative about everything and thinking that we were never going to find anything good, we went on vacation to NYC. Then I went on a walk to lunch – gotta get my Turnip Truck Hot Bar fix – and I had an idea….

We host Nashville Cocoaheads. They have their meetings at our office. Sometimes we buy pizza or beer for them. One of their challenges has been finding sponsors. Mostly because they’re busy with their day jobs, not to mention sourcing the actual speaker part of the events. And this isn’t the only group. We’ve also had emails from friends who needed money for chairs for their usergroup. Like, a lot of chairs. Their event is super successful, hundreds of attendees successful, but we still ended up sitting on the floor one time. (We did give money for chairs the time we were asked and now they have amazing venue sponsors who have their own chairs).

This sucks.

My friends are trying to create wonderful things for their peers and shouldn’t be worrying about these small things. We’re sitting on the floor. Or drinking water instead of beer. Or rushing from the meetup to dinner because the organizer only bought 2 pizzas instead of 6 because they were paying for it out of pocket and now it’s 8pm and I’m super hongry.

Now I know the point of usergroups is not pizza…or chairs. But these things help. You’re tired at the end of the day, and you’re taking that little bit of energy left to go to a thing and learn something new. It would be nice if there was sustenance there, or even better…free tickets to a conference or a free pass to a new software tool. Congratulations on doing something extra – here’s another piece of help.

So, I got to thinking…wouldn’t it be awesome if there was a tool to help my friends find sponsors for their usergroups quickly and easily? They wouldn’t have to cold email. They wouldn’t have to figure out how to make a pdf with their sponsorship packages when what they care about most is being a really good software developer. They wouldn’t have to buy the pizza themselves or email their friends for help (even though we like to help).

But wait….

is this a real problem? Or are my friends just bad at organizing meetups?

So I sent quick emails to friends who are organizers along the lines of “What do you think about a sponsorship tool for usergroups…” I got responses back that were practically epistolary novels about how YES. YES WE WANT THIS. OH GOD. YES. and then 1,000 ideas of what it could look like.

Well then….let’s proceed.

So I wrote some more emails… a ton of emails actually. And I had coffee, and beers, and Slack convos. And… it seems like a problem a lot of organizers have. Maybe not always on the same dire level but it’s still a task no one likes but everyone needs.

Sidebar: I LOVE OUR LOCAL TECH SCENE and how amazingly patient and helpful all of the Nashville organizers and sponsors are. You guys make me want to build this thing immediately, if only to give back to those who have already given Nashville so much.

Currently, I’m still in the process of having meetings with the Sponsor side of the equation but I’m looking forward to it.

I think we might have found a winner you guys. We’re passionate about our local tech community (and other ones like it), this is something within our grasp to build (sorry, massive email sentiment analysis idea), and maybe just maybe it can be profitable (sponsorship help for podcasts, for school clubs, for little league teams, for any grassroots organizer of anything).

Next up. More meetings. Competitive Research. TAM and monetization. What does this idea look like in feature form? We’ll keep you posted.

Let it go – Building a real MVP

In Startupland, the most valuable product is the Minimum Viable Product (MVP). Why? Because you didn’t blow your entire budget/savings getting there.

People often come in and start throwing this term around “MVP”. Requesting something along the lines of: iOS and Android apps, a web portal, and a full dashboard for all users and grandma! Oh and an admin portal with state of the art features as well.

This is not an MVP. This is your wish list. Your nice to have list. Your 2 years in list.

“But…but… I NEED to have these things or I won’t be successful.” you say.

Hogwash. Success is based on building the RIGHT thing. Not ALL the things. I know it’s exciting to start building but slow your roll!

While it’s not too hard to trim an initial feature list down by pairing some low hanging fruit, oftentimes you’re still not at your target budget. You may need to drastically slash costs to get to market or not get there at all. At this point we’re not talking about removing 2 questions from the signup page or changing out how fancy search is, we’re talking about removing entire areas or better yet – entire platforms.

Prove your business model before investing in it in multiple tech stacks.

Do you rrrrreally need that admin portal for your 25 users? Can you hold off on Android to see if what you have in iOS is really what users want? Do users really need to have both web and mobile access?

What should I cut when I don’t want to let go?

1. Assess features & users to find platform launch targets

Where are your users hanging out? Are they older? Younger? Are they turning to the web for this service? Is this something they need on the go? Assess your audience and the core features of your product to determine whether this is a web or mobile play to start (you can add more entry points later! This isn’t forever!)

2. Sweat Equity for Behind the Scenes

Even the great and powerful OZ understood the value of manual effort.

Do you really need all the management stuff automated? Weigh your time versus your cost of development. Is hiring a $10 an hour intern to review applicant profiles cheaper than building a machine learning service? Can you keep track and manage payments with excel and quickbooks instead of a custom point of sale system? Only upgrade/build your tools when the workload demands it not before.

3. Tech debt can be your friend (in the beginning)

Don’t polish and deeply invest in a feature if it isn’t proven yet. High traffic areas can be improved upon once their value is clear. What if you spend half your budget on a feature that when launched collects cobwebs from your so-called target audience? Make pivoting painless with lightweight development decisions.

Infinite runway? A budget as deep as the Grand Canyon? You may not have the make these hard choices, but I would still advise you to do so. It’s healthier for a product to be able to grow based on real world user experience. Give yourself the flexibility to change features and change messaging without having to visit 6 different codebases and remove 8 months of work. A simple product launch isn’t easy or straightforward, but it’s a smart one to start with.

Still having a hard time slimming your MVP? We’re here to help! We love creating products that built for success and don’t have a problem saying no (or strongly judging you for not being able to say no to yourself).

Need someone to question all your decisions and make helpful suggestions?

Initial Questions for a New Mobile App Project

It can be daunting to know the first place to start after you know you want to build a mobile app. I’m here to help. I can help you focus in your project goals on what makes sense.

Ultimately only you will be able to provide the core vision for what you need. As you ask the questions below, think through the lens of what needs to be in front of users first.

Let’s Build a Minimum Viable Product

Source: Kunal Naik

Since building technology costs money, having priorities will save you money. So what are the priorities? As we explore this question, keep in mind that it’s always smart to build a minimum viable product (MVP) first. Rather than having a little of everything that works ok, focus on building one aspect of your vision well so that it’s a great foundation. That may mean focusing on one platform before doing both iOS and Android. It may mean we should focus on core functionality before adding extra features.

Have an idea of what’s a must-have versus things that aren’t crucial. This will help you know what you should invest in first. It’s always better to get a smaller, great product in front of users, rather than an app that has more, but doesn’t work great. Having an MVP also helps you get to market faster, which has huge advantages. If you keep launching major updates to your app every 6 months, you’ll be learning what works and what doesn’t. This saves you money since you know which ways you need to pivot your thinking. It often doesn’t make sense to work on a large app for years, without getting feedback from users along the way.

That’s the critical piece of advice I’d give any of my friends who are involved in getting an app built. Keep in mind you’re building a MVP, and not the kitchen sink when considering the questions below. Here are some common questions I get when people reach out for a quote. This should help prepare you for a conversation with me.

Let’s Play Common Questions Bingo

If we wanted to build a Bingo board with the common questions that come up during a conversation about building an app, we’d be winning lots of Bingo. If you don’t know how to answer the questions below, spend some time thinking it over and reach out if you’re stuck. We can point you in the right direction.

You want to know: “How much will it cost?”

We need to know the answer to some of the questions below before we’re able to answer this one for you. In general apps are expensive to build, and zeros are involved. Thankfully a round number can get more focused as we learn more.

So what will we ask to get to the answer for that question?

What’s the big idea?

What makes this app unique and different? What will compel people to use it? What is that one thing that absolutely needs to come across when someone uses this thing?

What kind of features are you envisioning?

What are the core thing someone can do with your app? It can be helpful to see if you can distill your app in 2-3 user stories. A user story is a high-level description of one of the things a user can do with your app. Here are few examples:

As a car driver I can swipe my app while paying for gas to earn rewards.
At the gas station, I can show my app to redeem rewards at the counter and get a free Coke.
As a beer enthusiast I can scan a beer’s barcode to see details about a beer.
As a movie buff, I can search for a movie and mark it as watched.

Does this need to be an app?

Hang with me. Sometimes people will have an app idea that may not lend itself to the app format. If you want to build an app for writers that helps them build up their typing speed, it may work better as a website or desktop app, where people are more likely to have a keyboard when using it. What’s the advantage to people having this product on the go?

Who is this app for?

What’s your target demographic? Who will be using this app? This can help decide how the user interface works.

How do you plan to make money with this app?

This may sound a big harsh, but what’s the business plan? If you haven’t considered the longterm plan for how the app makes you money or meets your goal, you may be missing a core feature that needs to be in the app.

What’s the play? Should users be able to subscribe monthly to the app? Are there in-app purchases? Are there ads or messages from you or partners? How does a user give you valuable information such as their email address so you can reach out and tell them about your next rally for saving the rainforest? Does your app help you reach your goals?

Do you have a specific timeline in mind?

Do you have time pressures tied to your app? For instance, are you building an app that helps you create custom emojis that you’d like to release on the same week that the next Emoji Movie releases? Or do you have investors or stakeholders with expectations on when the app will be rolled out?

Based on the timeline, we may recommend what would be doable within your desired time window.

What other apps are your competition?

This question helps in a couple ways. Are you building an app that already exists? If so, what is your competitive advantage? If you’re building something different or better than someone else, how will that inform the features you’re wanting?

If you do have competition, what do they do that you also want to do? One advantage to not being the first on the scene, is that you don’t have to re-invent the wheel. You can likely glean from others what is already working in your space.

How fleshed out is the design?

Do you need a designer? Or is everything already mocked up? If you need some help with the ideation phase, we can help figure out a plan. Knowing how far along you are in this step will inform how long the process may take.

What devices will be able to run your app?

On what devices will your app be able to run? Can it only run on iPhones? Or just on Android phones? Both? What about tablets? Should the app look different for users using larger screen sizes? The answers to these questions greatly impact what needs to be built.

What other technology will accompany the app?

Do you also need a website?
Does an API need be built so that the app can access the data it needs?
Do you need an interface that allows you to edit or see user details?
Do you need analytics about the app so you can see reports of how people are using it?

Bingo!

If you have the answer to 5 of these you’re off to a great start. Keep going. If you don’t have all the answers, that’s totally fine. We can help you think through all of the questions above. These are just some introductory questions we often cover so we can start to figure out the size of your project.

Reach out when you’re ready to figure out your app’s next steps!

Becoming “Internet-Famous”

How to become internet-famous…or really how to have people talk about you, on the internet, IF you aren’t Miley Cyrus.

As you may already know, we built an app and wanted to share some of the details, as explained in previous blog posts:
The Ah-Ha Moment And What Comes After – The idea for the CaseCollage app, and Jennifer’s design experience

Building an App in 2 Weeks – App development process, Wiley’s analytical take

Roller Coaster App Store Review – App store submission hurdles (What is happening?!? Lets just have this baby already!)

Now comes article #4 in this series: Becoming “Internet-Famous” or “How to Make Friends and Influence People (Online)”

You cannot, cannot, cannot build an app and hope that people will randomly see it, download it, and shoot you to the top of the download charts. You have to let people know, and not just your friends and grandparents. If you’ve spent all your time building this beauteous, life-changing app you better be shouting it from the mountaintops. And the right mountaintops too. Here is how.

First thing to do. You should honestly have done this pretty early on. Decide who this app is for. Who is your target demographic? Is there more than one? Knowing your target audience should also be important when building your app – what will your future users want? What will make them happy? Jeremy Olson has a great (and very very detailed) explanation of how to do this, complete with making pretend users.

For CaseCollage we had two main audiences – the original idea source – tech/iphone fans who were horrified by the HON issue and the long-term users – people who love customizing their phones (tweens & designers).

Second thing. Find people who write to these audiences and find relevant press/similar items from these writers. Just like when mingling at awkward social mixers – find things you have in common. You love photos of your dog on your phone? I DO TOO. (In fact I just made this app that lets you put 35 photos of your cute puppy on your 5c case). See how I slid that app promotion in there? (It’s that easy).

Another tack? Find something the writer already wrote that can be compared with what you’re promoting – make sure your item is even better and more useful. Reciprocal linking IS THE BEST. You hate the HON issue? Oh look, I do too and here is how we can fix it (by downloading my new app of course). And you can link back to all your old articles about cases and the 5c in this article too. Google Juice. You’re welcome.

We sat down one Saturday while the app was in review and made a Google doc with every story written about the 5c cases in the past month, and every twitter handle/email/email form/facebook page we could possibly post on that was related to these stories. We crafted a form email with quick and straight forward facts about the app and contact information. In addition to this, we pre-wrote custom intros for every single contact we had. Example:

TechCrunch – Author’s tweet – https://twitter.com/panzer/status/37750512576783974
@panzer We hate the “hon’ too which is why we built this app – @CaseCollage. Make cool, custom inserts, cover up Apple’s mistakes. http://techcrunch.com/2013/09/10/do-i-like-the-iphone-5c-case-non/

Thing number three. After you’ve gathered all of these leads, you’re going to want to send them something they can use. If a writer comes upon any sort of hiccup at all, no contact name, bad screen shots, a confusing/unclear letter – they will hit the delete button. Tech writers receive hundreds of submissions a day – you need to feed it to them. More is more. Give them so many options, it will be a piece of cake. In our press kit – which was available as an attachment in all of the emails we sent, and at the top of our app website (also important) we included:

Another copy of the press release in .rtf format – no program required
The app icon in multiple sizes and formats – .jpg, .png, .eps
The app name/logo in multiple sizes and formats – .tif (transparent), .png
A bagillion screenshots – plain and in phone mock-ups – in high-res format

Some great resources I used on what to include in a press kit and how to write a concise & useful press release can be found here.

In total, I wrote 27 custom intros to pair with our form e-mail and press kit. It was quite a bit of work – about 4-6 hours worth. Then, once our app was approved. Wiley sat down and sent all of the items (again another 2-3 hours of work).

While this seems like a lot of work after you should be “done”. It is very much worth it – and gives you something to do while you’re going mad during the app review process. These items, press kit, research, and website/media kit make you seem like a professional developer and company with well thought out and worthwhile apps. Within 3 days we had received the following press:

If you read a few of the articles you can see how direct snippets of the press release and screen shots were used, as well as the video we made (thanks to our awesome friend Chris Paz)

It worked!

[responsive_video link=”https://www.youtube.com/watch?v=c7sXbno-Qvk”]

This was great for a first week push. We’ll go into more detail about what to do after the initial shipping high in the next post.

CONNECT:

WRITING