As a distributed organization, DjaoDjin relies on its contributors to make intelligent decisions for the better good. Following is the framework, guidelines and rule of thumbs we are using to deliver highly productive Software-as-a-Service solutions.
No detail is too small or too insignificant to be left unresolved.
COMMUNICATE BY WRITING ENGLISH
Our team is diverse culturally and linguistically, distributed geographically. It is mandatory to communicate in English. Prefer written form (email, Instant Messaging, etc.) whenever possible.
DEFAULT TO GROUP COMMUNICATION
Mass publication is the default behavior that support our distributed organization. Code, diagrams, marketing documents, leads, everything goes either in a public git repository or on the backstage website. Let recipients organize their feed and choose information relevant to them.
DEFAULT TO PUBLIC PUBLICATION
Keeping information private requires a constant investment in security. Inbound recruiting and marking is better served by transparency. Open source is fundamental to our economic success.
Most parts of the infrastructure are open sourced as stand-alone projects. Market research and interpretation are published. If someone else is willing to put the parts together they are welcome to do so.
Of course, customer-owned information, sales leads and business dealings are private. We also keep credentials, API keys, and deployment infrastructure private for obvious reasons.
Keep your eyes on the target. You cannot manage time. You can solely manage actions.
ONE STEP EVERY DAY
Make a list of everything you want to get done the next day. Pick one (and only one) thing you must absolutely complete and you are not going to bed before it is done. Worse comes to worse that is the only thing you will do Today but it will be completed by day's end.
YOUR HEALTH IS THE MOST IMPORTANT ASSET
Never forget to include lunch and dinner into your schedule.
SWEAT THE SMALL STUFF
Keep a list of actions you should get done by a specified date, especially for the little tasks that must be done but easily forgotten (reply to a specific e-mail, send a check to a provider, etc.).
SHARE WHAT SUCCESS LOOKS LIKE
Keep a list of actions towards the goals you would like to get done. When re-evaluating the goals, it is good to organize that list in meaningful buckets then order those buckets into a priority list. Communicate priorities to everyone involved. Use the actions in the associate bucket as a framework of what success looks like.
Schedule time regularly (once a day, once a week, once a month) to look at the goals. Are the conditions and time-frame under which each goal is meaningful still valid?
IT IS OK TO BE OFFLINE
Schedule time for online social activities (e-mails, twitter, etc.) and close off all connectivity applications outside those time periods.
REMEMBER WHY YOU ARE PRESENTING
There are usually two contexts: Either you are you delivering information or you are requesting a specific action. Either way you should have a framework in place to measure the results of a presentation.
KEEP IT SHORT
We are not in show business. Even if you deliver an entertaining performance, most people will feel robbed of their time when there is only superficial content. Longer presentations give you more chances to mess up. Keep it short.
For example, use Thursday instead of tomorrow and include the time-zone with every date and time. When you request an action, ask for it explicitly. Corollary: when you ask for two actions, results will be random.
PROVIDE CONTACT INFORMATION
Always include a pointer to your website, your direct e-mail address and an offer to engage in further dialogue with anyone interested.
REMEMBER THE MEDIUM
Either it is emails, videos, recorded or live, each medium has its own constraints and best practices. Make an habit to have two presentation decks, one for live presentations and one for sending by e-mail (20 slides max).
KNOW THE MATERIALS
Nothing beats training day-in day-out. Be prepared and know the key part of your speech.
For in-person presentations, use Guy Kawasaki’s 10/20/30 rule:
No font smaller than 30 points
For funding presentations, use the following outline:
What is this all about?
What are the risks and opportunities?
Go-To Market Strategy
Traction and Projections
What do you need?
We don't make a distinction between Business to Customer and Business to Business. In all cases , these are individuals that give us a chance to prove our product fits their use cases.
All information about the product should be available, easily searchable. Our customers can buy and use the product on their own. In that context, Customer support is built to unstuck people that hit the rough edges of the product. Customer support is directly responsible to build scenarios that drive helpful features into the product.
The analysis of customer feedback leads to write scenarios that can be translated into development requirements and triggers that can be monitored.
The first step in writing scenarios is the Goal Card that describes the individuals involved, the context and the desired outcome for those individuals.
Present the individuals involved in the Scenario, giving them names, a lifestyle background and job responsibilities. (useful qualifiers: Technical Buyer, Economic Buyer, etc.)
Timing: Nothing influences more customer behavior than the time of the year (An easy sale in the beginning of the year might just turn impossible at the end of a quarter). Location: Decisions made while walking on the street are not made in the same way as the ones sitting in a office in front of a computer.
CUSTOMER DESIRED OUTCOME
What result would the individual consider a success? This is also where we describe what an individual gains in the scenario (ex: Knowledge, Money, Social Capital).
When the Customer Desired Outcome is very specific, it is possible to list various alternatives that already exists. When the Customer Desired Outcome is more vague, it might indicate a more complex issue for the customer, one with a great business opportunity - Bingo! In this case, it is even more important to understand how the customer achieve the desired outcome - if at all. Bingo! Bingo!
Once a Goal Card has been written, design on the framework to achieve the desired outcome for the customer within the constraint of a profitable business can begin.
All steps in the sale funnel can be measured.
External trigger to start the action. That's where we measure the level of commitment of the individual towards achieving the goal card. This is where polls, market research and human intuition play a huge role.
Minimum action an individual has to do to enter the funnel. This is where we log action events.
What features (content or visual) have to exist for the individual to move forward in the funnel? This is where we insert the A/B testing phase.
What random surprising stuff outside the customer desired outcome can we give along the way to individuals stuck in the funnel?
How much money is the individual willing to pay to achieve her desired outcome? How many constraints built into the product to deal with free riders is the individual willing to bear?
The organization and operational guidelines for the technical team are outlined in the Software Development Process.