About · Posts · Categories · Projects · Mailing List

In my teens and twenties I played a lot of pickup basketball. Didn't matter where or with whom - as long as the rim had a net and the ball had air I was game.

I've written this in the past, but I continue to marvel at the life lessons you can identify in a pickup basketball game. Obvious ones such as teamwork and sportsmanship to less obvious ones such as mindfulness, confidence and restraint.

Certain days (or every summer day in NYC) the court would get crowded. It could be a two to three game wait before you get to play. So once you get on the court both teams have a lot of incentive to not lose. In basketball recognition comes to the scorers. Players that put the ball in the basket. So naturally the moment you get the ball you're making a play with the intention to score. The problem is all your teammates likely share this mindset.

Add in the influence of razzle-dazzle players like Steph Curry and Kyrie Irving whose effortless handles and pure scoring abilities are viewed with such awe that the moment a player touches the ball, they feel they must replicate Curry or Irving in order to mesmerize and garner the respect of teammates and opponents. It becomes less about the game and more about showmanship. It's a formula for losing your spot on the court and waiting another two to three games until you get back on.

So what do you do? Complain the person guarding you that your teammates are ball hogs. Or get confrontational and call out your superstar teammates to shoot less, pass the ball and make the right play. But this is pickup basketball, no one likes a player coach.

So shift your mindset, shift your responsibility: plug the hole.

If your team can't get a rebound, get in the paint and get rebounds. If an opposing player is dominating offensively offer to guard that player (always offer nicely). [1] If you need to set some picks to get teammates open, set the picks. The mindset is to do whatever is necessary to set your team up for success.

In most cases that means refraining from launching a three ten feet behind the line and turning around and celebrating prematurely as the ball drifts through the air. [2] It requires swallowing some pride and realizing that in this game your team doesn't need you to take ten shots. Identify the hole and make it a personal challenge to plug it. See how much you can influence the game even if you don't take a single shot. Teammates that know the game will appreciate you and will go out of there way to set you up offensively.

And if you win the game you get to stay on the court - and maybe in the next game you'll plug some offensive holes.



[1] Do it strategically and nicely. There is a lot of pride on the basketball court. If you just got scored on a couple times in a row it's embarrassing and frustrating to have a teammate tell you to switch on D. By telling you to switch with them are implying that you are not good enough to guard that player and they will now take over defensive responsibilities to show you how it's done. Don't be that teammate. Instead tell them they are doing a solid job, but you are trying to get better at defense and want to improve your skills. Ask them if they would be OK with you trying to guard their defensive assignment for a few plays. If they say no back off. But in most cases they will agree and appreciate you not showing them up on the court. It may also reciprocate back to you as they become more likely to pass you the ball in appreciation for your help defensively.

[2] Actually in all cases. Just don't do that. I'm a fan of confidence. But not at the cost of fundamentals. This new trend of shooting the ball and immediately celebrating by turning around and walking away because you "just know" that you made the shot is ridiculous. It's showboating and should be avoided.




The goal of this post is to document an approach to build an app. If you have an idea, this post outlines a path to build it.

It contains the knowledge I've gained in the last 5 years as a Product Manager in both startup and corporate environments.

It's a step-by-step guide I wish I had.

This post is intended for all levels of experience and professional backgrounds. No esoteric knowledge required.

Reading this post will be like plugging into the Matrix and uploading the "Build an App" program into your brain.

Topics include:

  • Thinking about your idea
  • Mindset
  • Mockups
  • User Stories
  • Project managing a development team

Throughout I'll provide examples from Bechant, an app two friends and I recently launched. Bechant is a tool that will email you a random selection of your Kindle Highlights.

If you have an idea or a desire to build a product, this post documents one way to do it.

Plug in.




Section A: Philosophical

Idea Part 1. (Visualize)
Idea Part 2. (A job to do)
Idea Part 3. (Excel test)
Idea Part 4. (Why build it?)

Mindset Part 1. (Be a minimalist)
Mindset Part 2. (Set your team up for success)

Section B: Practical

Mockups Part 1. (Introduction)
Mockups Part 2. (The good enough MVP approach)
Mockups Part 3. (How to: drawing approach)
Mockups Part 4. (How to: software approach)

Development Part 1. (Getting started)
Development Part 2. (Tech stack 101)
Development Part 3. (Tech stack 201)
Development Part 4. (The User Story)
Development Part 5. (Essential features for launch)
Development Part 6. (Project management)
Development Part 7. (Testing aka QA aka UAT)
Development Part 8. (Release to production)


Contact Me


Section A: Philosophical


Idea Part 1. (Visualize) top

Disclaimer: no amount of visualization and research can guarantee the success of your idea. You'll only know if you built something users want after you release your app.

BUT you must invest time to evaluate and refine your idea before you build it.

More time than you think.

Let me set the stage.

When you identify a problem and come up with an interesting solution, you lose objectivity. Your internal dialogue is overcome by observations that mostly reaffirm your idea. You think: it's a great idea, people need this to exist. Why wouldn't they use it?

You visualize a merry world where your product exists and users are using it. Yet you do not visualize the step between releasing your product and getting users.

What happens at that step? Where did all those users come from?

Say you just launched your app Turtbnb. It's Airbnb for turtles. Are users going to open the App store, know to search for "Turtbnb", download the app, sign up for an account, and become active users?

Your answer may be a resounding "YES"! Yet this optimism is not driven by logic or research, but by your fresh excitement from the novelty of the idea.

Move past your excitement and get to a state where you can evaluate your idea objectively.

Consider two mindsets. The idea phase and the experience phase.

The idea phase mindset lacks objectivity. It's the "this idea can't fail" phase. You don't understand or acknowledge the ways the idea can fail.

Here is something someone in the idea phase may say:

Users will search "Airbnb for turtles" in the App store and will download my app. Word of mouth is how I'll get thousands of users.

The experience phase mindset typically surfaces after you launch your product and have tried to acquire users. It's the "the idea didn't work because of..." phase. You've learned the reasons users didn't adopt your product and they make sense to you because you've gone through the experience of failing.

Here is something someone in the experience phase may say:

My target users don't search "Airbnb for turtles" or "Turtbnb" in the App store. They search and download Airbnb instead.

Why must you launch your app before some of the reasons it failed make sense? Do you need to go through 6 months of development to reach the experience phase? To learn those lessons?

Try to visualize today what you think you will learn six months from now. Where will you succeed? Where will you fail?

How does this visualization reshape your idea?


Idea Part 2. (A job to do) top

Your idea should solve a problem. A real problem.

Read this post for additional detail.

The takeaway:

When we buy a product, we essentially “hire” it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we “fire” it and look for an alternative.

What job will your app be hired to do?


Idea Part 3. (Excel test) top

Does your idea pass the "Excel" test?

Could I use an already existing product to solve the problem your product solves?

Say your idea is a tool that keeps track of my digital subscriptions (HBO NOW, Amazon Prime, etc.) and when they renew.

Am I more likely to A: take time out of my day to Google search for your tool, find it on the first results page, click the link, sign up for an account, and upload my data? B: create a spreadsheet. Or C: do nothing because I get email alerts when my subscriptions renew.

What is my level of motivation and pain to look for and discover your tool versus repurposing a product I already have.


Idea Part 4. (Why build it?) top

You should build this product because you need it.

Your idea solves a problem you have.

If a sufficient product already existed, you would use it instead of building your own.

But it does not exist so you'll build it.

You're creating something you will use.

Read Paul Graham's "How to get Startup Ideas" essay for more on this.


Mindset Part 1. (Be a minimalist) top

Be a minimalist.

You'll need to make a lot of decisions while building your app. Having a minimalist mindset will keep the process flowing.

You have a product idea but no guarantee that users need it. Worst-case scenario is you invest time and money to build a feature rich product, launch it, and get zero users.

To avoid this pitfall strive to launch your product to real users as quickly as possible.

To launch as quickly as possible, be a minimalist. Determine the absolute minimum you need to create so that you can test your idea with users.

Eric Reis in his book "Lean Startup" popularized the acronym "MVP". Minimum viable product. The MVP of your idea is the simplest iteration of your product that users can use.

For example Product Hunt started as an email newsletter. The founder manually added subscribers to the email list and sent out each newsletter. The email newsletter was the MVP of the idea. It allowed the founder to gather a user base and validate the idea before investing time and money to build the product you see today.

What's the MVP of your idea?

What is the minimum that you need in order to test your idea with users? The first version of your app doesn't need to be perfect. Does the first version even need to be an app?

Strive to build as little as needed. Be a minimalist.

Reid Hoffman founder of LinkedIn offers this MVP advice:

If you are not embarrassed by the first version of your product, you’ve launched too late.


Mindset Part 2. (Set your team up for success) top

It's your responsibility to ensure your team succeeds. How?

Set your team up for success.

Visualize yourself in the situation of the person doing a task. For example a developer writing code for a feature in the app.

Do they have all the information they need? Are the requirements clear? What challenges may they face?

By putting yourself in "their shoes" you'll be better equipped to anticipate roadblocks.

Avoid ambiguity. Ambiguity leads to miscommunication, frustration and delays.

To avoid ambiguity be explicit in your communication.

Don't assume your teammate knows what you know. Don't assume the task being worked on will be completed exactly to your expectations. If necessary, put in the extra effort to over-communicate to avoid ambiguity.

When challenges arise, focus on implementing processes to avoid repeating such problems. Focus on the remedy instead of a person to blame.

As an aside, if miscommunication does occur the remedy is two questions:

  1. What was the intended result?
  2. What actually happened?

Do whatever is needed to ensure your team builds the right product.

No task is beneath you. If no one is taking meeting notes, take notes. Follow up on things that need follow ups so that your team can succeed.

Do whatever is needed to ensure your team's success.

You'll know what will be needed. Your actions on those needs will correlate to your team's success.

And embrace that it's always your fault.

If you're part of a team or a process and something went wrong, of course it's also your fault. You could have looked harder. You could have raised your doubts. You could have double checked.

Set your team up for success.


Section B: Practical


Mockups Part 1. (Introduction) top

Mockups (aka sketches, prototypes, wireframes, storyboards) are pictures of the screens in your app.

Here is a mockup from Bechant:


You (as the product lead) should create the initial mockups. Doing so will help you think through the idea and how it will work. It will help answer fundamental questions such as what are the core features? How will users navigate from one screen to another? What will they see when they first log in?

Mockups are the first step to shift your idea to something tangible. They should be created before development begins.

Mockups can be used in various ways. To gather feedback from users so that you can affirm that you're building something they want. To be shared with a designer who'll use them as reference to create professional mockups. Or shared with a developer so that they know what needs to be built.

You don't have to be a designer to create mockups. Visualize yourself using the app and draw out what you see. It's your idea, draw it based on how you want it to function.

Jeff Bezos (Founder/CEO of Amazon) in his letter to shareholders offered this wisdom:

A remarkable customer experience starts with heart, intuition, curiosity, play, guts, taste.







Keep these nouns top-of-mind when creating your mockups.


Mockups Part 2. (The good enough MVP approach) top

The MVP approach with mockups is to focus on the app's core functionality. What will the login page look like? Where will the user go after they log in? What buttons will they see?

The goal is to create a basic outline of your app. Each image depicts a screen in the app, such as "login screen", "user profile screen", "logout screen", etc.

Focus on critical features that must be in the first version of your app. Don't overthink design nuances. For example think more about the buttons you will need instead of what color they will be.

Take a "good enough" approach and move on.

If a section of your app contains a button, but you don't know what label the button will have, just label it "Button" or "This button goes to user profile".


If the button is going to be blue, don't lose time determining what shade of blue looks best. Set a generic blue and refine it later.


If the mockup conveys the purpose of the screen, it's good enough.

Here is a sketch of the primary page users see after logging in to Bechant:


Here is mockup version 2 of this page:


And this is the live page on Bechant:


The live product may not look exactly like your mockups. This is OK.

In the above examples the last image includes the key elements of the previous mockups. Figuring out the key elements is your objective when creating MVP mockups.


Mockups Part 3. (How to: drawing approach) top

Here is a step-by-step guide to create your mockups. Adjust to your needs.

Start with a notebook and a pencil.

Draw a rectangle in the shape of an iPhone. It represents a blank mobile screen.

Determine the function of this screen. For example it's the landing screen (the first screen users see when they open your app).

Draw the elements (placeholder text, buttons, input fields) that will appear on this screen. Keep it simple. If an area is going to have a tagline or marketing text, you don't need the exact text at this moment. Draw a box and label it "marketing text".


Your goal is to determine the elements each screen needs. Specifics (such as button labels and marketing text) can be determined later.

Draw another rectangle and determine the function of this screen. For example it's the first screen a user will see after they log in. Draw the elements on this screen.

Add additional screens until you have a complete set.

Take a photo of each screen and upload them to Invision. Invision is an app prototyping tool. Use it to "connect" your screens and make your mockups interactive. (Invision calls this adding "hot spots").

Here is an example I created.

Visit Invision's documentation for detailed examples on how to use the tool.

Without writing any code you now have an interactive prototype that you can share with prospective users or your development team.


Mockups Part 4. (How to: software approach) top

In this approach use software to create your mockups instead of hand drawing them.

If you're on a PC I recommend Balsamiq.

If you're on a Mac I recommend Sketch or Balsamiq.

As described in part 3, start with an empty rectangle and add elements based on the function of the screen.

Here are examples of screens for Bechant I created using Balsamiq.




I added each image to Invision and created this interactive prototype.

Once you have a prototype you are happy with, you are ready for the development stage.

If you'd like additional detail on creating mockups check out my post on building a prototype.


Development Part 1. (Getting started) top

Development is writing the code that will make your application work. It includes "QA" (quality assurance) testing and launching your application to a live (production) environment.

Clear communication and a detailed development plan will save time and ensure the development team builds the product you are envisioning.

If you prefer to learn to code and build the first version on your own, dig into this post for a sense of what that entails.

I recommend exposing yourself to web programming basics so that development isn't a black box. By basics I suggest learning HTML, CSS and JavaScript.

Codecademy courses are excellent for beginners. Start with these two:

If you prefer books start with these:

Having familiarity with web technologies will elevate your confidence and increase your empathy when working with the development team.


Development Part 2. (Tech stack 101) top

Your technology ("tech") stack are the components that comprise your app. Like the engine, tires, and body frame components of a car, each serves a specific function.

For a web application start with a domain name and a host.

The domain name is the link to your site. For example Bechant.com or ForwardShapes.com. You will need to find and register a domain using a solution such as Google Domains.

You will also need a host. A host is a server (aka computer) that "hosts" the code for your app. When someone navigates to your domain (such as Bechant.com), the host sends back the app code to your web browser. Your web browser interprets the code and displays the contents of the app.

There are hundreds of companies that provide hosting services. Things to consider when selecting one:

  • Supported technologies
    • For example, if your app is built using Microsoft's .NET technology you need to find a host whose server supports this technology (different hosts support different technologies such .NET, Python, NodeJS, etc.).
  • Reliability
    • Also known as "uptime" - you don't want to be worried about your app being unavailable because the host is having server problems. This wont be an issue if you pick a popular host.
  • Price
    • A reliable host can cost $10-$15 a month.
  • Support
  • Security

Here are some popular and well known hosts: Heroku, Bluehost, Microsoft Azure, Amazon Web Services (AWS).


Development Part 3. (Tech stack 201) top

A basic web application has three components: a domain, a host that stores the app code, and a database for storing user data.

Your tech stack will be determined by your budget, time frame and application needs. Furthermore, you must determine what your team will build in-house versus using a 3rd party solution. This decision depends on several factors including time, cost, and how much flexibility/customization the 3rd party solution offers.

Let's go through the tech stack for Bechant.

Domain registrar: Google Domains.

Hosting and Database: Firebase.

Firebase is a mobile and web application development tool. All the code that creates what you see on Bechant is hosted (stored) on Firebase.

Firebase includes our database, which stores Kindle Highlight files users upload.

Before beginning development we decided that we would not spend time building our own database solution. Our core product feature is the Kindle highlights email. The database is an accessory that just needs "to work" without much customization. Therefore we decided to use a packaged database solution instead of building our own.

Email Service: Mailgun.

Mailgun is a tool that allows you to send customized emails in bulk. All Bechant emails that contain Kindle Highlights are sent by Mailgun.

Instead of building our own email sending tool from scratch, we were compelled by the reliability, pricing and ease of use of Mailgun. After creating an account and adding a few lines of code, we were able to start sending emails to users.

Additional hosting: Heroku.

Bechant sends users three emails per week with their Kindle highlights.

For this to happen a Node.js script on Heroku is scheduled to run Monday, Wednesday and Friday at 6:30 AM EST. This script communicates with Firebase and retrieves user emails and Kindle Highlights. It then creates an email for each user and sends the data to Mailgun, which then sends one email to each user.

Server logging: Papertrail.

This service provides activity logs of our servers. This is primarily for the development team so that they can troubleshoot any issues (such as users not receiving emails) that may arise.

Web traffic data: Google Analytics.

Used to collect anonymous data regarding how many users are visiting Bechant and the pages they are viewing (including time spent on specific pages).

Visual look of Bechant: Material-UI.

This is a user interface (UI) framework that provides pre-made components for creating user interfaces. For example the buttons you see on Bechant are created by Material-UI. We just customized the color.

Material-UI makes our app "responsive". This means the app will automatically resize depending on the size of the device. For example if you're viewing Bechant on an iPhone or iPad, all visual components will "respond" and shift to accommodate the different screen sizes. This allows us to have one codebase that supports any device and screen size.


Development Part 4. (The User Story) top

In a perfect world you send the development team a link to your mockups and they produce a bug free product that works exactly as you envisioned.

Reality is much more complicated.

As a developer writes code they may come across "ambiguous product situations". They are not sure how the product should behave.

For example say your application allows the user to upload a profile picture. What if the user tries to upload an Excel Spreadsheet file? What if the file is 1 kilobyte or 100 megabytes? How should the application behave? Should it display an error message? What does the error message say? What buttons are in the error message? Should you even have buttons? Are we sure we need an error message?

Ambiguous product situations are disruptive. Think of a developer as being on a Maker's Schedule.

There's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

Two things disrupt a developer: meetings and ambiguous product situations. Instead of focusing on writing code the developer is thinking about what they should be building.

Strive to optimize a developer's time so that they can focus on building. Minimize ambiguous product situations.

The User Story is a tool to overcome ambiguous product situations.

A User Story defines how a feature works. It explains WHAT should be built so that a developer can focus on the HOW.

The how is referred to as "implementation details". It's specific to the development tasks and code strategy. Exclude implementation details from your User Story.

A User Story should focus on a specific feature. Split a large feature into multiple User Stories. This makes the work manageable for the developer and the QA tester.

Here is a User Story template:

Story Title: My Story

Description: As a user I'd like to be able to do something.







Here is a User Story I wrote for Bechant:

Story Title: Highlights Collection page displays uploaded files

As a user I'd like to see a list of all files I have uploaded.


1. User is logged in and navigates to bechant.com/username

2. User has uploaded at least 1 file


1. User presented with "Highlights Collection" page (see mockup)

2. Table contains rows containing names of uploaded XML file(s)

2a. Exclude .XML extension from file name

2b. If long file name, extend name to second line (do not cut off file name or add ellipsis)

2c. Each row is numbered (first row number = 01)

3. Table should display all files that user has uploaded

The Story Title encapsulates what the story is about.

The Description is a sentence or two that describe the purpose of the story. It can be written from the perspective of the user.

Start a Description with one of the following:

  • As a user I'd like to...
  • The purpose of this story is to...

The Preconditions set the scene for your story.

What situation is the user in? Did they just click a button that brought them to a specific page? Did they upload a non ".JPEG" file that is 100 megabytes for their avatar?

Set the scene.

The Postconditions outline how the feature should behave.

They are bullet points and don't have to be complete sentences.

They are testable. They will be a checklist of everything to test when you are reviewing the feature. Once all Postconditions pass testing the feature is ready for release to production.

They are broad, yet specific. For example this Postcondition gives the developer a specific goal to reach:

Results appear in under 1 second

Postconditions provide clarity on how a feature should work. What is clarity? It's enough detail so that if you were the developer, you would know what needs to be built.

Be explicit in your Postconditions. Eliminate ambiguity. The more thorough your Postconditions, the more likely the feature will be built to your vision. Overly broad Postconditions leave room for interpretation and more points of failure.

If you have over 10 Postconditions (not counting sub-conditions), consider splitting them into multiple User Stories.

Here is another User Story from Bechant:

Story Title: Delete a file

As a user I'd like to be able to delete any file that I have uploaded to Bechant.

1. User opens Highlights Collection
2. User clicks on checkbox next to a file

1. Display action menu at the top of table (use Material-UI `app bar`)
1a. Color of App Bar should be: `rgb(97, 100, 137)`
2. App bar has `X` icon to dismiss the selection (clicking the X closes the app bar and un-selects the checked item in the table) - use Material UI close asset (https://material.io/icons/#ic_close)
3. Add link to `DELETE` (see Design-Inspiration)
4. Tapping on `DELETE` generates Material-UI `Dialog` element
4a. Use `Simple Dialog`
4b. Dialog Header text: `Delete file(s)`
4c. Dialog Body text: `This will permanently delete your file(s).`
4d. Dialog Buttons: [Cancel] & [Delete]
5. If user taps [Delete] permanently delete the files from Google Storage
6. Highlights Collection table should automatically refresh and no longer list the deleted file

Here is this story on our development board:


If you're new to User Stories start by writing several drafts for one feature.

Share these drafts with your development team. Collect feedback and revise the User Story until it's deemed optimal by the team. Your goal is to find the writing style that results in a clear and useful User Story for your team. This exercise will also help you discover how much detail the team needs in the User Stories.

Remember the reason for the User Story: to avoid ambiguous product situations.

If your User Story satisfies this condition, it's good to go!


Development Part 5. (Essential features for launch) top

Recall the Reid Hoffman quote mentioned in Mindset Part 1:

If you are not embarrassed by the first version of your product, you’ve launched too late.

Put together a list of "must have" features for launch. This list can include features such as:

  • User login
  • Password reset
  • Share data with Twitter

Your list will be determined by what you deem essential for launching the MVP version of your product. You will likely need less features than you think.

Here is the list of User Stories I deemed essential for the first version of Bechant:

  1. User can create an account
  2. User can log in and log out
  3. User can reset password
  4. User can upload one or more highlight files as XML, CSV, or HTML
  5. Email users 3 digests containing Kindle Highlights per week
  6. Highlights Collection page displays users' uploaded files
  7. Highlights Collection empty state
  8. About, How To Guide, Contact, Privacy Policy, and Terms of Services pages
  9. Bechant.com is responsive and supports mobile devices
  10. Highlights Collection Footers to indicate email status

If I wanted to launch even faster, I could have cut the list to the following:

  1. User can create an account (I would manually create accounts for users and email them their username and password)
  2. User can log in and log out
  3. User can reset password (Users can email me and I will reset their passwords)
  4. User can upload one or more highlight file as a XML, CSV, or HTML
  5. Email users 3 digests containing Kindle Highlights per week
  6. Highlights Collection page displays users' uploaded files
  7. Highlights Collection empty state
  8. About, How To Guide, Contact, Privacy Policy and Terms of Services pages
  9. Bechant.com is responsive and supports mobile devices
  10. Highlights Collection Footers to indicate email status

When considering cutting features, adopt the mindset to "Do Things That Don't Scale".

Do something manually until it reaches a breaking point that a programmatic solution could fix.

For example manually resetting user passwords does not scale. I couldn't do it manually if Bechant had thousands of users. However I currently don't have the "problem" of having thousands of users that need to reset their passwords. So why build a feature that solves a problem that I currently don't have?

Solve the problem when it actually is a problem. Often the future problem you're concerned about solving now so "you're ready for it" won't manifest.

Throughout the development process continue to re-evaluate essential versus non-essential product features.

Re-evaluate your Postconditions and cut them as well.

This will simplify your product and allow you to launch quicker.


Development Part 6. (Project management) top

At this stage you should have a complete set of essential User Stories and mockups. After development completes these Use Stories, your product will be ready for launch.

There is a system for tracking and managing the development process. It provides full transparency to the team as to what work is pending, in progress, and complete.

The system is a development board like this:


This development board is created on Trello.

Each card is a User Story. Each card has a:

  • Title (Story Title)
  • Description (Story description, preconditions, postconditions)
  • Attachments (Mockups)
  • Comments (For discussions and updates around this User Story)


The "status" of each card is based on the list (column) it's in. Your development board should have these five lists:

  1. For Launch
  2. In Development
  3. Development Complete
  4. Closed
  5. Backlog

For Launch is the "to do" list. On day one of development this list will contain all cards that need to be completed so that the product can be launched. It's the "must have" User Stories list.

Once a developer begins working on a card, they should move it to the In Development list. If a developer is writing any code for a card, that card should be in the In Development list.

Once a developer finishes writing code for a card, they move the card to the Development Complete list. This means the card is ready for testing.

After testing there are one of two outcomes. If the card does not pass testing, changes to the code need to be made. Thus the card should be moved back to the In Development list.

If the card passes testing, it is ready to be released to production. This means development work on this card is complete and it can be moved to the Closed list.

During the development process new feature ideas will surface. This can include development optimizations to your Closed User Stories, or new ideas for features to add. These ideas should be added to the Backlog list.

The Backlog list is a collection of all future "to dos". Development does not begin work on any card in the Backlog until it's moved to the For Launch list. Cards in the Backlog do not need to be fully written User Stories with pre and postconditions and mockups. They can be placeholders containing ideas or tasks to be done in the future.

You should have a compelling reason for moving a card from the Backlog to the For Launch list.

For example during the development process of Bechant we were going to support only XML Kindle Highlight files. But new information surfaced during the development process. We realized we should also support HTML and CSV files. Thus support for these file types became a card (User Story) that was moved from the Backlog to the For Launch list.

Be disciplined about which cards you move from the Backlog to For Launch. Your goal is to launch as quickly as possible. Thus consider the risk of delaying launch versus the added value this additional feature will bring.

If the value outweighs the risk, move the card to the For Launch list.


Development Part 7. (Testing aka QA aka UAT) top

When a User Story reaches the Development Complete stage, it's ready for testing. This is referred to as Quality Assurance (QA) or User Acceptance Testing (UAT).

It's essentially testing the User Story and how it performs with the application. Once the story passes testing, it can be released to production (to real users).

There isn't a "right way" to perform testing. Here is one approach.

Say we are testing the story:

As a user I'd like to be able to delete any file that I have uploaded to Bechant.

Start by performing the Preconditions. Set the stage.

1. User opens Highlights Collection
2. User clicks on checkbox next to a file

Now test each Postcondition:

1. Display action menu at the top of table (use Material-UI `app bar`)
1a. Color of App Bar should be: `rgb(97, 100, 137)`
2. App bar has `X` icon to dismiss the selection (clicking the X closes the app bar and un-selects the checked item in the table) - use Material UI close asset (https://material.io/icons/#ic_close)
3. Add link to `DELETE` (see Design-Inspiration)
4. Tapping on `DELETE` generates Material-UI `Dialog` element
4a. Use `Simple Dialog`
4b. Dialog Header text: `Delete file(s)`
4c. Dialog Body text: `This will permanently delete your file(s).`
4d. Dialog Buttons: [Cancel] & [Delete]
5. If user taps [Delete] permanently delete the files from Google Storage
6. Highlights Collection table should automatically refresh and no longer list the deleted file

Each Postcondition should either Pass or Fail.

If a Postcondition fails, decide if it's a "showstopper" failure or if it's a "fix later" failure.

For example say Postcondition #6 failed. After deleting a file the user has to manually refresh the browser in order for the file to disappear from the page. You must decide if this failure warrants sending the story back to In Development or if it can be Backlogged and fixed at a later date.

You should do some exploratory testing.

Try to "break" the application with edge cases. For example what if I refresh my web browser the moment after clicking the Delete button? Am I able to simultaneously click both the Cancel and Delete buttons?

See what happens when you perform actions that don't align with how this feature should be used. There is a difference between how you expect a user to use a feature versus how they actually use it. These are "edge cases". Try to recreate certain edge cases and see how your application performs.


Development Part 8. (Release to production) top

Once you complete testing of a User Story and have deemed it a Pass, the card can be moved to the Closed list.

The User Story is ready to be released to production. This involves sending a copy of the code from the "development branch" to the "production branch".

The development branch is the sandbox/staging environment where new code is written for your application. It's only accessible to the internal team. Real users cannot access it.

Once a User Story passes testing, it's ready to be sent to the "production branch". This is the branch that has code that runs when real users access your application.

After a User Story is released to production, you should perform some light "sanity" testing in order to confirm that the feature is behaving as expected on the live app.

If all works as expected remember to congratulate your team on another successful release!


Launch top

Congratulations - you are among the few that not only had an idea, but built it.

You wanted this product to exist in the world and now it does.

For your first set of users I recommend friends and family. They will be much more forgiving to the unforeseen glitches that come with a first version. Plus their feedback may lead to valuable enhancements that will improve the experience for future users.

So how do you get users?

If only I or someone had the "right" answer...

It's a combination of timing, luck, market-product fit, and more luck.

You built a product for a certain type of person. A certain profile. Where do people that meet this profile hang out? What do they read? What are their habits? Your challenge is to figure all of that out and to place your product there.

Jason Calacanis summed it up in two words:

Be everywhere.

There is no right way to do it. There is just your way. This post is part of my marketing strategy for Bechant. My strategy is to have you discover Bechant through a post that may provide you with more value than the product I'm promoting.

As a favor please share this post or Bechant with someone who may dig it.

Remember you're building a product because you believe in it's value. You believe that it's needed.

Share it with the world.

Good luck!


Contact Me top

A big thank you for reading this post. I sincerely hope it was helpful!

Did reading this post help you build your product? Tell me about it!

Did I miss something that you wished was covered?

General feedback?

Send me a note at andrei@forwardshapes.com

As a Product Manager I don't have a typical day. The only consistent element is change. And being at a software company change occurs quickly and often. Add to that a startup environment, and you get a fast-paced setting with shifting priorities and never-ending to do lists.

This quote by Reid Hoffman sums the feeling:

Starting a company is like throwing yourself off the cliff and assembling an airplane on the way down.

Here is an example of a recent workday. At the start I answered questions from our offshore development team related to feature requirements. I then did user acceptance testing (UAT) for a new Chromebook version of our app. This was followed by leading an hour-long brainstorming session with the product team where we established requirements for an in-depth data analysis project our product intern is doing. Right after I presented our operations team a new feature in their internal user management tool (I had spent the previous evening writing  an exhaustive list of test cases for the operations team to go through to test this new feature). This was followed by reviewing a list of open Android and Chromebook bugs (the builds are currently in beta) and adding user stories to our backlog. And there ended the first half of my day.

In order to be productive I strive to block distractions. I refrain from keeping my inbox visible while working. Email can quickly derail momentum so I keep it out-of-sight. I do the same with my phone so I'm not distracted by incoming notifications. I'll also keep headphones on and loop through albums I've listened to hundreds of times. Music helps me focus on the task at hand and provides a little extra motivation when a task gets difficult. These distractions I can control. But there are plenty that I cannot.

An in-person question from a colleague. A ping (Skype, Slack, Hangouts). The email with subject line "urgent". These impromptu "interruptions" or "distractions" are not bad, they are a natural byproduct of work life. They are part of the appeal of working in an office versus working at home in solitude. But they can be dangerous if they control you instead of you controlling them.

In my role an interruption is typically product related. How does X feature work. We should look into Y. Let's make sure development works on Z. They are all valid for the moment, but in most cases (production issue being the exception) don't need immediate attention. They can be deferred. And so I've developed a process for keeping track of these things while maintaining focus on current priorities. I'm the last line of support in order to see a task through. If it falls off my radar, it may not resurface again until a user brings it up.

My process is built around this principle: set it and forget it.

Whatever the item is, I want to  quickly capture it, and store it in a place where it will resurface the moment it should be addressed. For example, a question that needs developer input is asked. Instead of interrupting the developers (or my) flow, I open a shared meeting notes page (using Confluence) and record the item. Our development team is remote, and so we have  morning sync calls three times a week. Each call has an agenda of topics ranging from current projects to user stories that need grooming. And so during this call the deferred question resurfaces and is addressed. The meeting is set to happen anyway, so it makes sense to address the question then instead of the moment it first came up.

For this system to work you need to have the right tools and a certain culture. My toolset includes Confluence, Trello, Evernote, and Google docs. My team uses Confluence to capture meeting notes, product specifications, and general product documentation. I'll use Trello as my personal "to do" list for items that I differ and am responsible for. I'll use Evernote to capture personal notes when they don't need to be available to everyone on the team (otherwise I use Confluence). And Google docs (especially sheets) is a great all purpose tool that is used in harmony with Confluence. The beauty of each tool is I can quickly capture a deferred item, and because of the system, I know it will resurface at the right moment. I have browser bar shortcuts to Confluence pages and Trello boards. Once I have something to capture I pull up the page, capture the item, and continue with the task at hand.

Set it and forget it.

Once you have your toolset, you need to set your mindset to deferring things. This is a cultural shift that may not be openly received by your team. Especially if they are used to having immediate satisfaction. As each team and situation is different, there is no magic formula. You'll just need to start and manage expectations.

Constantly think about what do we build now versus later? Or more generally, what do we address now versus later?

Product discussions can be ambiguous - especially when discussing a bug or new feature. The discussion can quickly deviate to edge cases that become the conversations focus. Instead of striving to find the best solution for the known problem, "what ifs" dominate the discussion.

What if the user does this, how will our solution hold?

These questions put the group into an unproductive and awkward state. Feelings get hurt and morale destroyed as the group debates inconclusive questions. It's like debating whether green is a better color than blue. Valid arguments can be made for both, how do you pick one? Then someone adds purple to the mix and the group falls deeper into the endless debate spiral.

The group should have one person with a comprehensive understanding of the issue (bug, feature) being discussed. This person is the mediator.

The mediator in product issue discussions must know how the product works. Not at a code level, but at a practical level. The mediator can confidently answer how the product behaves when a user does X or Y action. The goal is to get the group to a decision. The mediator should not abuse their power by pushing their agenda. Instate a culture where the best idea wins. Guide the group to find that idea.

Knowing how the product works provides the mediator with the antidote for edge cases: the work around. Edge cases can destroy momentum as a variety of resources (developers, operations, QAs, etc.) are pulled in to create a solution for a problem that a small percentage of users might experience. The work around saves time and frees up resources to work on higher value tasks. It also provides  a solution if the edge case happens. But to know the work around, the mediator must know how the product works.

The responsibility of knowing how the product works falls on the Product Manager. Knowing what happens if I push button X when setting Y is on and how that impacts feature Z. Getting that knowledge requires dedicating time to coming up with test cases, running them, and documenting findings. Such tasks (that do not have a clear owner but are necessary to move the product forward) must be taken by the Product Manager. It's the non-glamorous aspect of a Product Manager's job.

The task of testing your product under specific conditions can be tedious and time consuming. But time must be made for them. Running the test yourself is the only way to truly know how your product works. Tasking a developer with looking at the code is not enough. You are not only pulling them away from other tasks, but they may overlook a particular code block that gets invoked in a particular case you did not explicitly state.

As a Product Manager, three elements comprise your responsibility of knowing how the product works: curiosity, effort, and time. Be curious, come up with questions on what happens if I do X, Y, or Z. Put in the effort to run tests yourself. Try to "break" the product. Find the delicate balance between delegating tasks and doing the things no one else will do. And although you can't make more time, you should allocate time so that you learn how the product works.

If you don't do it, who else will?

Startup companies are susceptible to building products that don't solve real problems. Instead of solving a real problem, they solve a fictitious one. The team fabricates a target user based on their idea - even though such a user may not actually exist. Herein lies the problem: since the idea came before the problem, the problem is a byproduct of the idea.

So the problem being solved may not actually be a problem for anyone.

Mark Hurst in his book "Customers Included" argues the importance of talking to customers in order to inform product decisions. He states:

Customers want a simple, unadorned solution to their problem.

It's an oversimplified but accurate depiction of an entrepreneurs purpose. To create a solution that solves a customers problem. To get there you need to start with the customer. Instead of dreaming what if scenarios you start with a tangible problem.

Dreaming what if scenarios can be fun and inspiring, but it puts you at risk of dreaming an idea that doesn't have a tangible problem.

I recently had an idea for a tool that would store the principals that you live your life by. It's LinkedIn meets About.me meets Twitter. A digital locker of motivational quotes. But what problem is this idea solving? I formulated a persona of a tech-savvy twenty year-old who meditates and does Yoga. Even though such people exist, do they have the problem of not having a tool to store their motivational quotes? Do they need such a tool? Is this a burning problem in their lives?

Even though the idea is interesting, the idea created the problem to justify the idea.

But the customer doesn't know what they want. So you'll build something visionary that will blow their minds and make them wonder how they lived without it. The probability of getting the idea right, followed by successful marketing/sales campaigns to get the product in the hands of your target users is very low.

Your idea may solve on one of three types of problems. A nonexistent problem. A problem the customer did not know they had. And a problem a customers knows they have.

The what if blank page brainstorming approach will likely get you an idea for a nonexistent problem. To get an idea that solves one of the other two types of problems requires a more focused approach. Whether it's talking to customers, doing research, reading (a lot), you need to focus not generating an idea, but on identifying a problem.

Once you know the problem you're solving, formulate your solution.

Don't do it the other way around.