Business Developer Entrepreneur
Getting a software product to market is hard, very hard. Delays and failure come for many reasons, but perhaps the biggest is the lack of communication between the people use the app or website and those that build it.
If you are an entrepreneur starting a startup that has an app or web site at the heart of the product offering, even if the industry your product serves is traditionally low tech, you are a tech entrepreneur. If you are the person who isn’t writing the code, managing the server, or compiling the data, you are probably a non-technical, tech entrepreneur. You are the "business" side of the house and product management will be a big part of your duties, at least until you are so big someone else is doing this for you full-time.
Many years ago, I attended a local "product management" conference. One of the most eye opening moments at the conference was listening to an abrasive woman participate in a group discussion. She was a product manager (also often referred to as a "business analyst") and was asking, or more accurately complaining, "How do I get developers to build what I tell them to build?"
She went on to explain how she loved her job, she dedicated herself to understanding what her customers needed, what they truly wanted, how to deliver the best communication experience ever, and truly demonstrate that she cared about people from whom she was gather requirements. She dutifully documented all requirements and placed them in the team folder. AND… she couldn’t get the developers to read her documents.
What was eye-opening to me was that this woman seemed to be excellent at half her job. She failed to understand that she had two "customers". She was the middleman, the bottleneck through which all communication flowed, but it only flowed one way and what came out the other side was documents. She didn’t take the time to understand what her developers truly needed, how they preferred to communicate, what was most helpful to them in their jobs, and what information was critical to their success. She treated her two customers very differently.
As a developer, I’ve worked with a business analyst like this more than once. Often they have been trained on the "right way" to build absurdly long documents and use case diagrams when most of the time a developer only needed a decent flow chart, a short list, and a 30 minute discussion to review the details. Business people build these things "for developers" but isn’t it odd that I’ve never heard of one of these people receiving training from a developer? Why aren’t the developers on the team teaching the business analysts and product manager how to deliver the most value to their teams? At a very minimum, shouldn’t the business analyst ask the developer what would be the most valuable information to deliver and in what format? Sometimes this happens in great development shops, often it doesn’t.
At this point I should probably point out that I did spend more than a year as a business analyst in the medical software field. I’ve been in the shoes of persons on both sides and I know how to deliver both up and down the communication chain. The key is to understand and cater to your audience, on both sides.
Having the right team communication dynamic is key in any organization, but critical in a startup. Scrum is a very popular project management technique used by many software teams, but the most important aspect is constant communication with everyone involved. Whoever is going to be angry if the project is late or is missing features should be interacting with the development team weekly, if not daily.
As the business person on the team, responsible for directing the developers on what to build, here are some tips that may help you get your team headed in the right direction regardless if you use a formal project management like Scrum or not.
Don’t build requirements documents for developers. Create bulleted lists, sketches, and short stories. Organize and store them in the same place, but perhaps not a single document. Documents take way too long to create and are rarely ever read, at best they are skimmed. Bulleted lists of "the product must do this" are perfect for developers. Developers can cross them off as they build them, and nothing is missed. This is also now a list for the testers to follow.
Do you remember word problems in math class? Everyone hated them. Why? Because it was a pain to dig through paragraphs of text to dig out the important parts. It was easy to miss something. Requirements documents are the adult version of the dreaded math word problem. Stories are good, but as background not as requirements. If you need a story, make sure it includes the "WHY". Why are we building this? Here is an example.
Requirements like this are good for developers because they are concise, easy to read, and each item on the check list can be crossed off. If you are using Scrum project management (you should learn about Scrum), these bullet points easily become work items. This requirement can be printed on a single page, taped to the wall, a developer can walk up to the wall, pull off this one item to work on. No big documents to dig through. Individual items that can be divided among the team.
You should get continual feedback from customers both before and after the product exists. Show them sketches and prototypes, and give them early access. This is how I like to encourage requirements gathering.
Customer -> Product Manager -> Developer
The product manager had a lengthy discussion with the customer one-on-one, perhaps with observations of the problem the software is going to solve, the work environment, etc. The product manager makes identifies the requirements, but also takes note of unique problems and features for further discussion. The product manager takes time alone to review the notes, cleans them up and creates the bulleted lists needed for the developers, but does not share them yet. The product manager, customer and developer meet together. Ideally this would include most if not all of the developers and multiple customers. The PM begins to go through the notes they took, but this is not a recitation of what was found nor a reading of what is written. Rather, the PM should moderate and guide a discussion between the customer and the developer on the more unique aspects that were discovered.
Terry (Project Manager) - "When I was talking to Tom (customer) he shared something interesting with me about bounce rates in their old product on the registration page. Tom, could you tell Jennifer (developer) what you told me about getting people signed up?"
Tom - "Yes, well, we found that people are very hesitant to give you their email especially if they don’t know if they will like the app yet. We made the email optional and still had the same problem. We found that if you make people think about creating an account at all, it is too permanent for some people and they leave. We did some tests and found that if you suggest a username and remove the password field, those who wouldn’t create an account otherwise will say "whatever" and just take the suggested name to keep moving forward in the app."
Jennifer – "Interesting I haven’t ever heard of anything like this, but it makes sense. Do you just want to make a user name like ‘Temp1464’?"
Terry – "Tom and I actually had an idea of making a name that is a little more fun like ‘SpeedyMongoose’ can we do that?"
Jennifer – "I’m sure we can figure something out. Is it ok if we add a number to the end? That will result in hundreds or thousands of extra combinations and will make it easier to generate them and avoid duplicates. They need to be unique, right?"
Tom – "I’m ok with a number on the end and yes they need to be unique. They can always purchase a name change later if they decide they like our product, but regret using the random username."
Jennifer – "Do you want to let the user change their name for free if they used a random name?"
Tom – "Oh, I hadn’t thought of that. Can we only let it be free if they do it in the first 10 days?"
Jennifer – "Yes that should not be hard to add."
Terry – "Excellent. So I already had all this stuff on the list for the new quick registration screen from the discussion Tom and I had earlier, except the number to the generated username, I’ll add that. I’ll also add a requirement to allow them to change their username for free, if we can figure out how to do it before 15 days."
Tom – "10 Days"
Jennifer – "The requirements Terry wrote said we should prompt them to change their temp password after 15 days, can we ask if they want to keep or change their username when we force them to change the password? Combine the features into one? Either both after 10 days or both after 15 days? It will be quicker to build these features together."
Tom – "Oh, I thought I said 10 days for password change when I talked to Terry earlier. Good idea. Let’s make it 10 days and do them both at the same time."
Terry – "Thanks Tom. I must have written that down wrong. I’ve got it now. Jennifer, Tom, do you have any questions for each other before we move on?"
Jennifer – "Actually yes. This whole changing your username is brand new. I haven’t heard that before. This is sort of a big deal. Everything you do in the system is tied to your username. Changing it in one place, means changing it everywhere. That might be really hard to do in the database because of primary and foreign keys. We might need to change our primary key. I’m not sure we can do this without a big refactoring.
Terry – "This is getting a little more technical than we should probably go for this talk. Tom based on WHY you want quick registration, I assume this is very important to get more people to use the app, and we wouldn’t want to lose this feature, so if you had to choose between not having the option to rename your user account, or spending extra time to change the system to support a rename, which would you rather have?"
Tom – "I guess I’d like to find the cheapest solution to a rename. We absolutely need the quick registration, but I’d hate to then lose customers because they didn’t like their "GreenHorse99" username and didn’t want to re-setup a new account to get a new name."
Terry – "Ok, that helps with priority."
Jennifer – "Maybe we can let them setup a new account with the name they want and transfer everything they have done, as long as the emails match, would that be ok? Either way, I’ll find the best path and get back to you."
Tom – "A transfer would work if the other options are too much work. Let’s see what you find. It sounds like you are already on the right track to achieve the primary goal of getting them in quick, but leaving options for a rename."
Terry – "Perfect. Tom, I will let you know what Jennifer finds and you can decide if you want to go with it, or have another meeting to discuss it with the three of us. We can also make more adjustments to the requirements when we meet next."
This is a very plausible discussion that could happen between three people. Let’s review the important things that happened here, that may not have happened if the product manager had used the more traditional approach of talking to the customer and developer separately, without a combined review session.
Traditionally, many product managers would consider this discussion a waste of time for the customer and developer. However it is easy to see how this short conversation had the potential to save days of extra work and thousands of dollars.
Product management is an art. There is no doubt balancing cross discipline communications can be a tricky feat. Most startups struggle with this and honestly many die as a result. The key is great communication. Work together to keep each other on task. Always discuss the "Why" of product requirements. Make sure everyone understands the underlying goals of a feature. Keep documentation as simple and concise as possible. Use a system that allows the things that need to be done to be simply reviewed, tracked, completed and verified. Create relationships across the entire breadth of the business.
Use a requirements management system your developers want to use. Even a simple list manager like Trello.com can work for small teams if you don’t use a complete Scrum process. Store any requirements documents in a shared folder, like Dropbox.com. Saving documents in a system that can track changes, is very nice, especially if you use a system that developers understand, like Git. If your document system doesn’t have change tracking, prefix the name with the year month and day so the documents can be easily sorted to find the most recent changes (2016_11_29_QuickRegistration.docx), and change the file name every time you modify the document to update the date. Include a header section at the top of every document that identifies what was changed and when.
2016_11_28 - Added username change rules
Use flow charts. I didn’t really discuss them here, but I’ve found more than any other chart you could build a flow chart is often the most important to a developer. Flow charts have decisions, they imply status, define rules and show logic. These are the things developers need to build to create apps and system. Additionally, if the business person takes the time to work through the process in enough detail to build a flow chart, they will likely uncover many of the "what if" scenarios before a developer makes a bad assumption, or needs to stop and ask for more information. Flow charts are a great way to boost your communication efficiency with your tech teams.
Finally, this process does not end, ever. Even when the product is almost ready for release and later in the market, the process of reviewing with users, testing, and polishing continues. Keep adding items to your work lists with the same level of discussion, review and documentation as before.
There are entire systems you can use to manage your project. Many of them are great. However, if you decide not to adopt any of them for a variety of very valid reasons, using these tips for documenting and communicating will get you a long way. Sometimes, too much structure in a startup can also be a problem. This is an easy way to establish good habits. Some day you can establish a more formal product management process, until then, focus on your communication.