Note for Early Contributors i

[babbltd-admin]

Purpose of the note:

• orient contributors to the goals and methods of early-stage product creation at London Street

This note's sections are:

1. Problem
2. Solution
3. Flagship Product
4. Prototyping
5. Company Direction
6. Work Planning Method
7. Team Work Routines
8. Progress Update Options

Problem

To date, we studied the general ‘market problems’ and day-to-day challenges faced by London Street’s initial target segments, namely Tradesmen, labourers, farmers, and other kinds of business people that wear every hat while on the go and on the job.

In our company’s Pitch Deck, the problem has been stated this way:

Successful ‘solopreneurs’ who are always on the go quickly encounter the mountain of business administration. They are trying to deliver value to their customers but sales and record-keeping consume their energy. Productivity drops from having to wear every hat while relying almost exclusively on mobile apps. Less output equals less profit. Revenue and re-investment into the business slows down, growth stalls, and far too many talented people succumb to the harsh conditions of entrepreneurship.

As an early contributor, you are helping to build up early versions of an initial product solution, which will evolve through many iterations. It’s important to keep in mind that for any startup, the envisioned solution to the ‘Big Problem” is not the product. The solution is a “unique approach” that’s needed based on the diagnosis of the consumer issues. The solution identifies a general vision and a framework within which products can be tested and brought to market.

Solution

From London Street’s “Unique Approach” slide, aka the General Solution:

A “Business OS” based around classic tools & the daily business routines of individuals. Releasing a core set of integrated apps is the first step toward creating purpose-built hardware & new approaches to business education.

Flagship Product

BASICS App (twitter: @mybasicsapp / instagram: @basicsapp) is a proprietary application that supports the fundamental activities of self and business management. This includes but is not limited to actions such as saving contacts, notes, reminders, and values. This tool is based on a evolving System Architecture meant to support a Personal Operating System for offline and online devices, otherwise known as the "Business Assistance System".

The Business Assistance System ("BAS") is made up of several independent tools that work in harmony via a proposed Controller Tool.

The main components of the BAS i.e. the BASICS System are:

1. Profile - Link to Repo
2. Contacts - Link to Repo
3. Notes - Link to Repo
4. Ledgers - Link to Repo
5. Logs - Link to Repo
6. Record - Link to Repo
7. Calculate - Link toRepo
8. Account - Link to Repo
9. Controller - Link to Repo

Over time other primary and secondary tools will be added to the BAS to ensure its secure and reliable operation. While we commit to operating a general BAS upon which BASICS App and other Web applications can rely on, a major Company Goal is to enable the independent deployment of BASICS Systems by individuals and groups. Minimal hardware requirements is a must.

Early versions of the BASICS App do not require a completely coded system in order to operate. Instead, product development will take place alongside system development. The coding of mobile applications will incorporate principles from the BAS, as company resources and commitments permit. Once BASICS App exits Beta it will be operating with maximum integrity.

Prototyping

The goals for BASICS App v1 are centred on Profile Creation and Management. As V1 is iterated, the codebases for Notes, Account and Contacts will also take shape. Coding for Controller, Calculate, Ledgers and Logs will be reserved for subsequent versions.

Company Direction

London Street's Executive Team is planning and carrying out high-level work using the same agile methods as the Product Team. The Marketing and Customer Discovery teams are being run in the same manner.

The company overall and each product team are anchored by Guide Docs which include Vision, Purpose, Roadmap and a few others. At the Company level, these documents feed into non-public Competitive Advantage Information (Unique Customer Insights, Innovation Entryways, Market Capture Strategy, and Segment Capture Tactics). These support our general Work Plans which are shaped by high-level Company Goals. These Goals are the equivalent of Company Objectives tied to the creation of products and services. An example of a real Company Goal is Support Full Control Over Usage & Sharing of Personal Names.

Based on these Company Goals, we articulate Product Design Goals meant to outline the What and Why for new product features in existing or new products. An example of a real "PDG" is Legendary, Memorable and Isolated Experience of Editing Name Fields Resulting in Elevated User Trust. For any given season, Company Goals are translated by Management into Product Design Increments (PDIs) which set the scope and pace of work for product development.

Work Planning Method

Each team's work is based on modified forms of the Agile method for project management. We use Scrum Meetings, Work Sprints and Sprint Reviews to achieve goals and steadily increase the pace of our outputs. For the Product Team, the Company's Product Design Goals are converted into practical user-centred language. These features are then broken down by technical staff into Modules, Components and Single Functions. Based on the Product Team's understanding of the needed and queued features, they set down Product Development Goals which translate user-centred Features into programmer-centred language. For example, the feature "Quickly Save Names Information" is translated into "Independent Names Management Section in Main Profile Screen".

All Company-level planning is carried out in the Team Repo. It's named this way because everyone regardless of their role or expertise is part of the broadest conversations at the company. The main hub for these conversations is the Team "Discussions Board". All kinds of high-level discussions and note-sharing takes place here, the main ones being Company Goals and Product Design Goals.

The Work Planning Method outlined above can be pictured like this:

Team Work Routines

The majority of work for all teams is documented in Github. Drawing on the explanation and graphic above, the process looks like this:

Management Team does the following

1. Convert a discussion about Company Goals into an Issue, or directly create an Issue labeled Company Goal.
2. Document every Product https://github.com/londonstreet/team/labels/Design%20Goal as comments on each Company Goal's Issue page or Discussion page.
3. Select the options button ("...") for your comment on the Issue or Discussion page, then select "Reference in new issue".
4. For Product Design Goals, the repository will remain "Team".
5. Go to newly added Issue for the Product Design Goal.
6. Document each Product Development Goal on the Product Design Goal's Issue page.
7. For Development Goals you wish to bring into the Product Workflow, select "Reference in new issue" again.
8. Select the relevant Product Repository to add the Development Goal to, e.g. BASICS-App.

Product Team does the following

1. Repeat above processes for converting Development goals into Features, Modules, Components and Functions.
2. Functions represent singular, focused events supporting user goals and interaction objectives.
3. Working Product Increments are achieved through Sprints centred on coding for functions.

Scrum / Agile Method of Working

We are using the Scrum / Sprint / Review method to advance our work week-to-week. Every Sprint attempts to achieve a "Working Product Increment" that adds to or sets the scene for a Working Product Version. The scope of each Sprint is also metered by reference to listed Product Development Goals and the identified features that support them. Milestones set by the Company and the Product Team leader are the final piece that prioritizes the order of work and the content of sprints.

Sprint Reviews happen at the beginning of many Scrum Meetings but may also take place sometime preceding the Scrum.

General Plan for Scrum Meetings at London Street:

1. Previous Sprint (review session):
   • goal/aim(s), tasks, outstanding tasks
   • top takeaway(s), rose/bud/thorn
   • summary of previous sprint backlog
2. After this meeting (sprint planning):
   • quick summary of Working Product
   • confirm current Product Goals
   • confirm next set of tasks/goal ("The Increment")
   • last sprint ~ carry forward or postpone tasks
   • identify additional tasks for new sprint
3. Obstacles I face:
   • resource issues
   • tools/infrastructure restrictions
   • info/research/time constraints
4. Heading off:
   • confirm roadwork / roadworker(s)
   • reconfirm tasks
   • set time boxes

Progress Update Options

Ongoing and required updates from team members can take many conventional and creative forms. The main spaces for sharing work updates are Github Discussion threads and Issues pages, as well as various Discord channels on the Team and BASICS servers.

Additional guidance about project communication can be found here:
Company Note: Updates, Information Sources, Team Tools