Are you a non-technical founder with a great software idea? Ready to take the plunge but want the “secret” to successfully managing software development? Well, it's not a "secret" at all - it's a disciplined methodology we are going to share with you. This presentation is designed to provide entrepreneurs with a blueprint for successful software development and technology implementation. The unfortunate reality is that quality software development and technology implementation is not readily available to most startups and small business entrepreneurs. Great entrepreneurs are met with small thinkers when searching for a development team via online freelancer sites, or the recommendation of a friend’s cousin who may code on weekends. Or they are faced with development companies that impose business models that do not align with the entrepreneurial spirit.

1. A Proven Software
Development
Process for the
Non-Technical
Founder
If you can dream it, you can build it.

2. It's a great time to be
a Non-Tech
Founder!
There are more
Non-Tech
Founders of tech
start-ups than
ever before
Bill Smith
High-school dropout, never
learned to code, founded
Shipt, and sold to Target for
$550M
Katrina Lake
Degree in Economics
Founded Stitch Fix, which
went public and is valued at
$3.1 billion.
Jessica Scorpio
Bachelor of Political Science
Founded Getaround, which
has raised $443M total in
funding
Whitney Wolfe
Herd
Non-technical
Founded a $1B company,
Bumble
Tim Westergren
Musician, founded Pandora
in 2000
Jack Ma
Former English
teacher, founded Alibaba in
1999 (after being rejected by
several colleges, the police
force, KFC, and numerous
funding attempts)
Brian Chesky
Bachelor of Fine Arts,
founded AirBnB in 2008

3. • Investors are demanding that
companies turn a profit... not just “have
potential”
• Non-Tech Founders are domain experts
solving real world problems
• Software development is accessible to
everyone
It's a great time to be
a Non-Tech
Founder!
There are more
Non-Tech
Founders of tech
start-ups than
ever before

4. • A failed software
development project
can cause a business to
never launch as it
runs out of time and
money
• 50% of our clients come
to us from a failed
experience
And it's not because
of a lack of skill.
Majority of
software
development
projects fail

5. Failure is usually not due to a lack
of skills (there are tens of millions
of skilled software developers in
the world) … it is due to a lack of
clarity
It's due to a lack of
CLARITY
Majority of
software
development
projects fail

6. There's a lot to unpack here.
“Clarity” is the process
of collaboratively
defining the delivered
results of a stated
goal.

7. • “Stated Goal” is the clearly articulated solution
to a problem or drive
• “Delivered Results” is the final product meant
to satisfy the stated goal
• “Define” means to eliminate, or at least
minimize, assumptions and ambiguity
regarding the delivered results
• “Collaboratively” means that all stakeholders
(clients, developers, PM’s) work
synergistically
• “Process” states there is a step-by-step way to
define the delivered results
Let's reverse engineer
this statement.
“Clarity” is the process
of collaboratively
defining the delivered
results of a stated
goal.

8. • The construction foreman
has been asked to "build a
rental unit."
• Let's see how this unfolds...
A sad, but often true, story.
Let's run through an
example of a lack of clarity

9. “Build me
a rental unit”

11. “That’s not
what I
meant...
I want a residential
rental unit”

13. “That’s not
what I
meant...
I want something
smaller”

15. “No! Way off.
I want it to be
a permanent
structure!”

17. “Close...
but I want it
to accommodate
4 families”

19. Learned from painful and expensive
mistake.
“That’s it!
Let’s put in a
pool... but first,
let’s me provide
some clarity
around the
pool!”

20. • Survey the land
• Create a blueprint
• Construct to milestonesThis is an easily accessible and
well-understood analogy.
Let’s examine the 3
main phases to
building real estate
from the ground up

21. Survey the land
• What is the exact square footage and exact
boundary lines?
• Are there water, sewer, and utility lines?
• What is the zoning?
• What types of structures can be built, and what
limits are imposed by the city?
• What type of structure do we want to build?
• What is a ballpark budget for this project?
An overview and high-level
exploration
Let’s examine the 3
main phases to
building real estate
from the ground up

22. Create a blueprint
• Working collaboratively with an architect,
create a detailed blueprint of the proposed
structure that will inform a foreman and crew
of constructions workers
• Create milestone of construction – what will
be built and when – a construction roadmap
• Plan for inspections for each milestone, and
clear acceptance criterion of the milestone
before proceeding to next phase
• List all assumptions prior to construction
A detailed plan of implementation
Let’s examine the 3
main phases to
building real estate
from the ground up

23. Construct to Milestones
• Following the blueprint, build the structure
according to the blueprint
• Inspect and approve construction at each
planned milestone
• Provide timely feedback as market conditions
change (example, upgrade appliances to
stainless steel) and understand that each
change will affect delivery time and costPlanned phases of execution and
delivery
Let’s examine the 3
main phases to
building real estate
from the ground up

24. Benefits of following a proven process
The finished product
Let’s examine
the 3 main phases
to building real estate
from the ground up

25. • Project Survey
• Project Blueprint
• Coding in Sprints
Software development is intense,
complex, and involved knowledge-
based work
Developing quality software on-
time and in-budget requires an
even greater commitment to clarity
because software development is
intense knowledge-based work is
infinitely involved and complex

26. • User Stories
• Proposed Features
• Requirements
• Identified Constraints
• Recommended Budget and Scope
An overview and high-level
exploration of your project
Project Survey

27. • A user story is a description
of a software feature from an
end-user perspective. It
describes the type of user,
what they want and why. A
good user story creates a
simplified description
of requirements.
An overview and high-level
exploration of your project
Project Survey:
User Stories

28. • Features are the software’s functionality.
Each feature represents the users’ needs
and/or goals.
• Features are defined by the users’ roles:
• Customer / end user
• Administrator or business owner
• Etc.
An overview and high-level
exploration of your project
Project Survey:
Proposed Features

29. • A requirement is how the software
must achieve its functions (features).
• A list of conditions or capabilities the
software must meet to be considered
done.
An overview and high-level
exploration of your project
Project Survey:
Requirements

30. • Constraints create the perimeters for
the software.
• They can be technical or business,
but they narrow the focus of
development to those perimeters.
An overview and high-level
exploration of your project
Project Survey:
Identified Constraints

31. • The scope defines all the features
and requirements to be developed
and delivered.
• The budget and scope are planning
tools that evolve. Many factors may
impact the final product.
• Your development shop should help
you understand the variables that will
impact budget and scope.An overview and high-level
exploration of your project
Project Survey:
Recommended
Budget & Scope

32. • Designs
• Flow diagrams
• Wireframes
• Mock-ups
• Architecture diagram
• Identifying and confirming development
assumptions
• Unit tests evaluation
• Acceptance criteria
• Milestones
• Proposed team structure
• Proposed sprint and delivery schedule
• Anticipated costs (line itemed)
A detailed plan
of implementation.
Project Blueprint

33. • A flow diagram is a powerful
visualization tool that demonstrates
the user experience in its entirety.
• Through a flow diagram,
stakeholders can easily identify and
update actions or movements within
a very complex system.
A detailed plan
of implementation.
Project Blueprint:
Designs – Flow
Diagrams

34. • Wireframes are the visual skeleton of
the app.
• They rely on simple line diagrams
and stock font without any images or
color.
• Wireframes allow stakeholders to
visualize how users will interact with
each screen and make changes as
needed easily and quickly.A detailed plan
of implementation.
Project Blueprint:
Designs – Wireframes

35. • Mockups provide a sense of the final
design of the software through
colors, images, and typography.
• Mockups validate that the desired
look and feel of the User Interface
(UI) has been achieved.
A detailed plan
of implementation.
Project Blueprint:
Designs – Mockups

36. • An architecture diagram is a
graphical representation of all the components
that are needed to run your software. This
includes things like servers, databases, mobile
devices, etc.
• It is essentially the ecosystem of your software.
A detailed plan
of implementation.
Project Blueprint:
Architecture Diagram

37. • An assumption is defined as “a thing
that is accepted as true or as certain to
happen, without proof” or as “a fact or
statement taken for granted”.
Accordingly, we define software
assumption as software development
knowledge taken for granted or
accepted as true without evidence.
These assumptions are seldom
documented and less frequently
validated by the people who have the
knowledge to verify their
appropriateness.
A detailed plan
of implementation.
Project Blueprint:
Identifying &
Confirming
Development
Assumptions

38. • Unit testing is code embedded in
your software to automatically run
tests on specific functions.
• Unit testing can be valuable because
it protects core functionality while
new code is being developed.
• In the long run, strategic unit testing
minimizes down time.
A detailed plan
of implementation.
Project Blueprint:
Unit Test Evaluation

39. • Acceptance criteria are the
conditions that a software product
must meet to be accepted by a user,
a customer, or other system. They
are unique for each user story and
define the feature behavior from the
end-user’s perspective.
• Well-written acceptance criteria help
avoid unexpected results and ensure
that all stakeholders and users get
what they expect.
A detailed plan
of implementation.
Project Blueprint:
Acceptance Criteria

40. • A milestone marks progress in the
software project.
• Milestones are predefined goals that
visibly represent several related
tasks being completed.
An overview and high-level
exploration of your project
Project Blueprint:
Milestones

41. • Typical software development teams
consist of a project owner, a project
manager, a team lead, a number of
developers spanning specialties
required for the project, a UI/UX
designer, and a QA tester. Smaller
projects may see a reduction in team
members, and often a project
manager will also co-serve the
product owner role with the client.
A detailed plan
of implementation.
Project Blueprint:
Proposed Team
Structure

42. • Sprints are time-boxed periods of one week
to one month, during which a project
manager, team lead, and development
team work to complete a specific product
addition. During a sprint, work is done to
create new features based on the
user stories, requirements, and acceptance
criteria. A new sprint starts immediately
after the current sprint ends, and the client
has provided sufficient feedback to
evaluate and start the next sprint. The
concatenation of sprints form a
delivery time-line and schedule.
A detailed plan
of implementation.
Project Blueprint:
Proposed Sprint &
Delivery Schedule

43. • Anticipated costs are separately
identified and line itemed.
• This demonstrates a strong effort
was made to analyze the product’s
features and requirements to
understand the effort needed to
produce it with the quality required.
A detailed plan
of implementation.
Project Blueprint:
Anticipated Costs
(Line Itemed)

44. • Test scripts / automated tests (where
applicable)
• Coding
• Code Reviews
• Unit Testing
• Testing
• Client demo
• Client feedback
• Evaluation of feedback
• Planning for next sprint
Implementation and
delivery of your project
Coding in Sprints

45. • A test scripts represent a set of
instructions that will be performed to
determine if the system functions as
expected.
• Test scripts fall into two broad
categories: manual and automated.
• There are various means for
executing test scripts.
Implementation and
delivery of your project
Coding in Sprints:
Test Scripts /
Automated Tests
(where applicable)

46. Implementation and
delivery of your project
Coding in Sprints:
Coding
A lot of this:

47. • Code review (sometimes referred to
as peer review) is a software quality
assurance activity in which one or
several people check a program
mainly by viewing and reading parts
of its source code.
Implementation and delivery
of your project
Coding in Sprints:
Code Reviews

48. • Discussed earlier, but here again to
emphasize the role of testing, and
the role of unit testing with manual /
automated QA testing.
Implementation and
delivery of your project
Coding in Sprints:
Unit Testing

49. • Test scripts were discussed earlier,
in the context of creating the test
scripts. This is the phase of the sprint
where the scripts are executed and
the results documented.
Implementation and delivery of
your project
Coding in Sprints:
Testing

50. • Work completed in this sprint is
demonstrated to the stakeholder in
the overall context of the work
completed to date.
Implementation and
delivery of your project
Coding in Sprints:
Stakeholder Demo

51. • Based on the demo, stakeholders
provide ideas, suggestions, or even
pivots, based on several factors like
actual implementation and usage,
market conditions, customer
feedback, and/or investor demands.
Implementation and
delivery of your project
Coding in Sprints:
Stakeholder Feedback

52. • Client feedback is collected and
analyzed in context of the current
sprint, the upcoming sprint, and
future sprints. In the scenario of
pivots, the sprint schedule is typically
reconsidered.
Implementation and
delivery of your project
Coding in Sprints:
Evaluation of
Feedback

53. • The next sprint is planned based on
evaluation of the feedback. The next
sprint may not change much. Or the
next sprint's priorities may
significantly change. Developers
who work with founders need to be
flexible but structured in the sprint
planning.
Implementation and
delivery of your project
Coding in Sprints:
Planning for Next
Sprint

54. When software development
projects are properly planned and
executed, software applications are
delivered on-time and in-budget.
Ready to Launch!!!
The Final Product

55. Yes, there is a counterpoint
Counterpoint to
a well-planned
project

56. “Move Fast and Break
Things.
Unless you’re breaking stuff,
you’re not moving fast enough.”
- Mark Zuckerberg

57. Move Fast and Break
Things
This software development
philosophy is romantic and
captures the essence of the
Silicon Valley swashbuckler hero

58. Move Fast and Break
Things
• Mark Zuckerberg has a near-limitless
supply of developers and money to break
lots of things to find 1 that works.
• Making the leap of faith that you do not
have hundreds of developers, I am going
to advise that you steer clear of “move fast
and break things,” and instead follow a
proven plan for software development that
will maximize your chances of success.

59. • There is a lot to remember from this
talk, and I encourage you to utilize the
details to help you evaluate the
selection of your next software
development vendor. To facilitate this,
we are handing out checklists you can
use when doing your due diligence. Ask
your proposed dev team how they
address each item on the checklist. If
they satisfy your answers, offer
a competitive rate, and you have a
good connection with them... they may
be a good choice for your next project.
Vendor Selection
Checklist

60. • Are you OK with staying up late
thought the night and early AM
working with a remote team? If so,
you may be able to save some
money - if not, then the difference
in time zone may affect the long-term
quality of the project, as well as time
and budget.
Vendor Selection
Checklist:
Time Zone

61. • How much experience does your dev shop or
developer have?
• Have they worked on and seen a variety of
projects?
• This helps them brings a multitude of
solutions to the table.
Vendor Selection
Checklist:
Experience

62. • Are they invested in your project and their
work?
• Is the company stable and on a growth
trajectory?
• Or are they a couple of guys working
nights and weekends for some extra
money, who may (and I have seen
this more often than not) decide to stop
working on your project and cease all
communication?
• Will they be around when you need help in
a month, a year, or 5-years from now?
Vendor Selection
Checklist:
Stability

63. • Dev shops will range anywhere from
a low of $25 / hour in the Far East to
$150-$200 / hour in the United
States. Know these ranges so you
can set expectations, and budget
accordingly.
Vendor Selection
Checklist:
Price

64. • Are the project managers and
developers in the dev shop a cultural
fit? Do they share the same cultural
values that you embrace? If the answer
is no, then when crunch time comes,
there may be undue friction. As
Peter Drucker is famed for saying,
“Culture eats strategy for breakfast”;
ensure there is a good cultural
alignment.
Vendor Selection
Checklist:
Culture

65. • Do they understand business models
and start-ups? Let’s face it, your
product will launch and make a
success or failure of your business.
Ensure that your dev
shops understands your business
goals as a start-up.
Vendor Selection
Checklist:
Business & Startup
Mindset

66. • Scope changes happen in every
project. Do they have a defined
process for how to handle scope
changes the allow you to be flexible
enough to modify direction while
understanding the change’s impact
on cost and time? Will they strategize
with you on the business and costs
analysis of the change?
Vendor Selection
Checklist:
Change Requests

67. • Do they have experience building
secure applications, like HIPPA
compliant apps? Can they identify
the right time to bring in experts on
risk analysis and threat assessment
that focus on a specific areas of
cyber security?
Vendor Selection
Checklist:
Risk Analysis

68. • Use this same checklist for “rescue projects.”
These are projects that failed with a previous
software developer or dev shop, and you are
moving to a new developer or dev shop.
The checklist can also help
with rescue projects
Rescue Projects

69. For "rescue projects", use the checklist to:
• Stop and step back
• Evaluate what is missing from the Survey
and Blueprint and fill in the missing items
– it may also be necessary to color in and
clean up the existing items.
• Then get back to coding – in the long
run... this approach will rescue a failed
project and save time and money.
The checklist can also help with
rescue projects
Rescue Projects

70. • We live in a time of unprecedented growth and potential. More
billionaires will be minted in the 2020s, and a few trillionaires, than
ever before because of convergence of technology into our everyday
lives. We are in a decade of converging emerging technologies that
changes the landscape how we work, play, and live. Non-Tech
Founders who are domain experts with inspirational ideas will lead
the pack.
• The world is your oyster... you just need to take that first step.
Now...
is your time.