App Advice Archives - LunarLincoln

Sep

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. We are here to help. We 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 we get when people reach out for a quote. This should help prepare you for a conversation with us.

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!

Sep

Gif TV: A LunarLincoln Product

If you’ve ever perused our blog or Twitter you might have noticed that we like GIFs. We think they’re a great medium for injecting humor or emotion into what could otherwise be a dry industry-specific topic. If you’ve ever been in our company Slack or on a text thread – you’ll notice we sling just as many GIFs there too. We just can’t get enough of those little moving-nuggets of fun.

What feels like 1 million years ago but was actually 2014, I found an article on Lifehacker (remember Lifehacker?) about building a little screen that showed GIFs. I was fascinated, immediately ordered the parts and put one together (although not without copious cursing due to the inaccurate instructions). This lil’GIF machine resided on the wall in our office for a few years but was more frequently out of commission than active. It was the definition of a buggy hack.

I loved it. I loved the serendipity of a random GIF being served up as well as the mindless entertainment of seeing what comes next. If you’re a fan of the TikTok For You page, you know exactly what I mean.

So, when we first started clearing time in our schedule to work on passion-projects at LunarLincoln, we each made lists of potential ideas we’d like to work on. Wiley made a huge list of tools that could help him at work/life (to do apps, API validators, proximity photo services). Me? I made a huge list of fun, useless things (80s photo filters, mean mail and….the Gif TV).

I wanted to see our office Gif TV as a real product, for real (non-technical) people. It could show your favorite GIFs, GIFs from friends, GIFs for topics, reaction GIFs, etc. Whatever hit of 5 second dopamine-laced entertainment you needed.

Wiley begrudgingly agreed (since I promised to do most of the work). And so we dug into building Gif TV.

Below is a very quick summary of the journey but we’ll be breaking these into longer posts in the coming days. Keep checking back for more product and GIF content!

Initial Plans & the Reboot

Initially our plan was to package up the original raspberry pi/screen concept with a companion app to select and serve the GIFs since the initial version you had to upload GIF files by hand to a random database. But, as I started to source components, and look at 3-D printing cases, and see how long it took to assemble them by hand – it was seeming a more and more complicated (and not profitable) venture. Hardware is hard y’all.

But what if the app WAS the tv?

This would be a simple solution. We build apps. Why muddy it up with hardware?

BUT, I did still want some sort of physical component for two reasons.

People are so fickle about paying for apps – a physical product still holds more “value” for consumers. We could recoup costs better upfront than trying to build out all the infrastructure for some sort of subscription service.
I wanted a physical engagement with the gifs. We already have a million ways of digitally access gifs, but what about a “present” version. I pictured the app languishing with the 1200 other random things you downloaded into your phone. That physical stand will be sitting there, asking – don’t you want to stream some gifs today?

So the GIF TV was reborn – an App + a Stand.

Coming soon – Learn more about the app planning process and the stand production process.

Gif TV as a way to learn new tools/technologies

The Gif TV project wasn’t just a way to share our office Gif TV with friends though. We wanted some low-risk projects to test new tools on.

Personally, I wanted to take Figma for a test run without using a client as a guinea pig (and on something more complex than twiddling with the pre-built templates).

Wiley had wanted to check out Flutter. After years of nay-saying cross platform solutions, a few close friends had managed to convince him that Flutter was worth a gander. Cross-platform still is only best used for content-driven apps versus sensor driven apps and Gif TV fit this niche perfectly.

Gif TV seemed like the great solution for both goals. Fun product + acquiring new skills. Double win.

Coming soon – Learn more about why we’re fully on the Figma train now and about Flutter and when it’s best to use.

Gif TV as a foray into new activities (crowdfunding, marketing, startup sites)

We weren’t just learning new skills for our careers though, we did a little stretching into adjacent areas too.

I learned more than I ever wanted to know about laser cutting and CNC machines. I built stand prototypes with my Cricut, had early versions cut with Ponoko, and now I have a cardboard box with more random Gif TV stand pieces than you’d even need.

We tried out new kind of promotional websites – falling in love with Carrd for it’s simplicity and inexpensive entry point for landing pages and Big Cartel for our shop.

We stretched our marketing skills again for the first time since CaseCollage. We gained a newfound respect for how lucky we’d been with that first launch and just how many new things there were to learn in this go-round. Product Hunt, social campaigns, cold emails – they were all areas where we felt we were just dipping out toes and learning there was a lot more to learn.

Coming soon – Learn more about our experience with Product Marketing.

Gif TV as an enjoyable product for friends

At the end of the day, we haven’t seen as much traction as we’d hope for our little Gif TV. But that doesn’t mean it can’t still happen or that I’m not still enjoying my personal Gif TV streaming on my desk right now. We’ve learned a ton about Figma, Flutter, Kickstarter, Product Hunt, lasercutting, ecommerce and social media. I think we’re better positioned for future product launches and we have a great little product here as a case study.

We’ll likely push Gif TV some more during the holiday season and I’ll work on some alternative marketing for it in the meantime.

Want to check out Gif TV for yourself?

Visit the site where you can download the apps, purchase a stand, or learn more about all the ways you can enjoy your own Gif TV.

Oct

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.

Apr

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 Abe…I don’t want anyone to steal my idea when I talk about it to them.
But Abe…I don’t need to test with users – I know exactly what they want.
But Abe…I don’t have time to test with users, we have to be first to market. I need to start building now.
But Abe…I don’t have the budget for fancy user testing.
But Abe…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 Abe…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 Abe…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 Abe…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 Abe…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 Abe…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 to LunarLincoln. We’re happy to help you build the next big thing (or next tiny thing).

Email us. (We’ll get right back to you. Promise.)

Feb

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!

Jan

Hourglass for Jira

Over here in LunarLincoln land we’ve been working on a few things….client work, mentoring, getting Little Doors in the dang App Store (I’ll cover that more in another post). While all of this has been happening, we have a little internal project that’s been chugging along making some background profits.

Oh hey there…

What is Hourglass?

It’s a tool we built a year ago when an extremely popular time tracking plugin we used in Jira basically blew up for a few days. Those were busy and important days where we didn’t want to have to track time manually, so Wiley spent the weekend hacking together a little tool we could use ourselves in the meantime. Goodbye expensive plugin behemoth with a shaky support record – hello Hourglass – our own simple but scrappy time tracker.

We used it for a few weeks, made some improvements, and thought, “Why not share this with others?” Maybe there are other people out there who also just want something simple and straightforward. Start your clock, stop your clock, that’s it. So, we put it in the Atlassian Marketplace, threw up a website and that was it….for a while.

Then we started getting sales checks. Not massive amounts, but a little something nice from Atlassian each month. We decided to show our little time tracker some love, so we made a few updates: new Atlassian UI, a dashboard and some more analytics.

To date, users of Hourglass have logged almost 3 million minutes of billable time. They’ve created 25,000 worklogs. They are based in 50 countries and a surprising number of different industries.

Which brings us to the present day. While we are still on our epic search for the best business idea ever, we thought we’d make a short pitstop in Atlassian plugin-land and build a few more nuggets of code that don’t require long term marketing. A few more monthly sales checks wouldn’t be too bad too. We’re pretty intimate with the ins and outs of Jira. We have some gripes that could use a plugin and there are probably some people out there with the very same complaints. Do you have any Jira complaints? “It’s so annoying when….” ‘s ? Send them on over! (jennifer@lunarlincoln.com or twitter @lunarlincoln). It’s not the next Facebook, but it’ll certainly make your day to day a bit more pleasant – one tiny tool at a time.

Oct

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.

Aug

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).

Jan

Is Your App Idea Special?

Let’s be honest – app ideas are hard. The world is big and fast-moving and what’s hip today might flop tomorrow. Having what feels like a good app idea is only the first small step in building a successful product.

The Process

So, imagine you’ve dreamt up a great new app idea, what should you do? The very first thing any entrepreneur should do is check if their idea already exists, but not for the reasons you might think.

You’re not looking to see whether the door is shut in your face, you’re looking to see if the idea has potential in the market. Most app ideas are not purely original. Tons of people are having the same great idea each and every day. But that’s okay! Other people with similar ideas prove that it is a good one! Seeing competitors shows that there is a need and it is feasible concept.

Realistically, you ARE going to find a few apps that do some similar behavior to what you’re imagining. Whether those apps are wildly successful or quietly unnoticed, you’ll have to innovate and find ways to improve upon these existing products. Think about features that are missing, designs that can be improved, and new ways to monetize. Do you think this market has room for another app? How can you attract the most attention?

What if you go app hunting and can’t find anything even close to your app idea? In this scenario, your app idea typically falls into one of three cases:

Your app idea is original and nobody else has thought of it
Your app idea has been discovered to be too costly to develop
Your app idea isn’t appealing to enough users

Naturally, you want to be in the first category, but what if you’re not? This is hard, and you’ll likely need to reach out to potential users and gauge their interest. Continuing down this path is certainly risky but can still be very successful.

The Bottom Line

The harsh reality is that most app ideas are uphill climbs. You’ll work, you’ll iterate, you’ll advertise, and sometimes you’ll fail. Failure is a tough pill to swallow, but it’s a fantastic learning opportunity. Did you make a mistake when assessing the viability of your idea? Did market conditions change? Or did someone else beat you to the market while you were developing? No matter the outcome, use this experience to craft your next great app idea.

Jun

The Secret to Estimating

What’s the secret

Here is the ONE WEIRD TRICK (ok it’s more of a process) to knowing how long it will takes to build a mobile app. Here are the steps:

Gather relevant information at the beginning of a project.
Divide the project into smaller chunks of work.
Even smaller! (If your work items are too broad you’ll tend to underestimate)
Make a best guess about how long each bit of work will take.
Track your time while building the app.
Check how close you are at the end of the project.
Repeat steps 1-5 a hundred times.

It’s not really much a secret. It’s obvious that getting better at estimates is largely a function of putting in the hours. However the better you are at estimating your work, the smoother a project will go.

Why is it Important?

Accurately estimating how long a mobile app takes to build is key to a great working relationship.

If we tell you an app will take 2 hours and it takes 200 hours, you’ll be stressed. If we tell you it will take 200 hours and it takes 2 hours, you may be happy, but you’ll likely stop trusting us.

Great estimates build trust. If our estimates are close to reality, you can trust us to help steer what’s best for your company, not only for delivery date predictions but also for budgeting and business decisions.

Here’s an example. Say you want as many iPhones users as possible to be able to use your app, which means supporting a different number of devices, running older and newer operating systems. If we know it really will take another 10 hours to support those 5% of people on really old phones, we can provide the accurate data to make a business decision (are those 5% of people worth 10 hours of development time?).

With great information, you can make great decisions.

What are the pitfalls?

Becoming an Estimate Connoisseur takes time, but there are a few things always increase accuracy. Most of it comes down to communication.

Before becoming a software developer, I held the common stereotype that developers were holed up in a corner just cranking out code. This is true for periods of time, but you may be surprised how crucial communication is to a great app. Often there’s a direct correlation on a technical team between the quality of communication, and the code.

The same lesson rings true in the realm of estimating.

It all comes down to asking questions and listening well. For instance, an estimate based on assumptions is often inaccurate. If I assume a portion of work was already done when it wasn’t, or if a task will be very simple and it is much more detailed, there are usually some painful outcomes. A project may take more time or money than originally expected, or the scope of the project may have to be paired down.

Asking clarifying questions always makes sense for both you and us when an estimate is being put together.

What about my app?

The real question is how long will it take to build YOUR app? And how much money will it take?

That’s something we can figure out for you once we learn about the project. It all starts with a conversation about your idea. We’d love to prove that we’ve gotten pretty good at this.

12 3