How to Build Software If You Can't Write Code

By @rustysf (russwallace.com)
How To Build Software
If You Can’t Write Code

Who This Presentation is For
• You want to build a startup software company

• You’re not a software engineer

• You’ve never worked at a tech company before

• You’ve never worked at a tech company before
• You believe “perfect” is the enemy of “good”

Why Learn to Be a Product Manager (PM)?
• If you're not an engineer, then you're everything else

Why Learn to Be a Product Manager (PM)?
• If you're not an engineer, then you're everything else
• You need to know how to build the whole company
• At ﬁrst, you're a PM
• Then, you're sales (or “Biz Dev” if you want to sound cool)
• If lucky, you get to be an exec (culture, long-term plans, M&A, etc)

Why Listen to Me?
• No sacred cows: I just want to get shit done
@rustysf

Why Listen to Me?
• No allegiances: I don't debate the ﬁner points
• Not interested in the “perfect” PM style, methodology, tool, etc.
@rustysf

Why Listen to Me?
• No allegiances: I don't debate the ﬁner points
• Not interested in the “perfect” PM style, methodology, tool, etc.
• My opinion:
• Your success doesn't hinge on “perfect” product management
• Pick the most widely recognized, get organized and move on
@rustysf

In My Experience
image credit: http://xkcd.com/1349/

Product Management = Non-Technical Building
• Software companies don't start needing sales or culture

• They start needing a good software product
• Everything else comes after that

• Software engineers build software

• You're not a software engineer

• You're not a software engineer
• You're only useful if you can help engineers build
reasonably scalable code as fast as possible

What a PM Does
• Make the decisions about a product that determine if it
succeeds

What a PM Does
succeeds
• What to build & when it needs to be built

What a PM Does
succeeds
• Taking responsibility for what to include and what to leave out

What a PM Does
succeeds
• Approving progress as it happens

What a PM Does
succeeds
• Approving progress as it happens
• Any admin on the project:
• Setting up accounts, signing up for tools
• Removing “blockers” (things big & small that prevent engineers from
continuing to build)
• Anything engineers don’t want to (or can’t) do

What a PM Does Not Do
• PMs DO NOT code

• PMs DO NOT code
• It's great to be technical, or to learn coding in order to
communicate, but don't try to commit code

• PMs DO NOT code
• PMs DO NOT decide how a product is built

• PMs DO NOT code
• PMs DO NOT decide how a product is built
• When/Why is not How
• Engineers choose language, coding tools, libraries, etc (excepting
choices that affect business aspects of the product, such as IP
rights or functionality)

Side Note On Choosing What to Build
• This is where you can help as a “business guy” (or gal)

• Talk to everyone who is relevant to your product
• Talk to every potential customer. Take detailed notes on what they
want.
• If you're really good, sell a product before it's built

want.
• DO NOT: read books, guess, or ask your friends and
family what they want

want.
• DO NOT: read books, guess, or ask your friends and
family what they want
• Once you know what to build, refer to this presentation to
get it built

Before We Dive Into Details…
image credit: http://www.gapingvoid.com/

Being a PM is Difﬁcult
• Becoming an “A-level” PM takes years of experience,
mistakes and mentors

• This presentation will help you look like a “B”

• Repeat: a few slides can't make you an “A”
• That's OK: you don't need to be an “A” PM to be an effective
non-technical founder

• Repeat: a few slides can't make you an “A”
• That's OK: you don't need to be an “A” PM to be an effective
non-technical founder
But you can't be a “C”

Product Methodologies (“How to Build”)
• Almost as many as there are coding languages
• Waterfall/BDUF
• Agile/Scrum
• Extreme/kanban

Product Methodologies (“How to Build”)
!
SKIP IT:
You can cover 80%+ of engineers you'll work with by
understanding a scrum-based agile format

Agile? Agile what?
• “Agile” is a philosophy/methodology that boils down to:
• Break up the project into discrete deliverables

Agile? Agile what?
• Communicate constantly

Agile? Agile what?
• Focus on product goals, not features

Agile? Agile what?
• It’s the opposite of:
• Creating lengthy, detailed product speciﬁcations before getting
started

Agile? Agile what?
• It’s the opposite of:
• Creating lengthy, detailed product specifications before getting
started
• Locking engineers into inflexible final product requirements before
knowing what bugs/issues will arise

And Scrum is…?
• A set of procedures that are considered agile

And Scrum is…?
• No one actually implements them the same (AFAICT)

And Scrum is…?
• No one actually implements them the same (AFAICT)
• For your purposes, just know about:
• Stories
• Sprints (and the rules regarding these)
• Retrospectives

The Details in Four Steps
image credit: http://www.andertoons.com/

Step 1: Stories
• “Stories” are the way you should think about product
features

Step 1: Stories
features
• Think in terms of the user: what goals does the user have with respect
to each feature?

Step 1: Stories
features
• Think in terms of the user: what goals does the user have with respect
to each feature?
• Goal is to think through every detail of the user’s experience before
building

A Basic Example of User Stories
• To sign into your software:
• Story 1: User can register for an account

• Task: user must enter full name, email and a password [include ﬁnal
designs for what this page looks like]

• Task: forms must validate that the email address is valid

• Task: after registering, user is taken to their Account Proﬁle page [include
destination link]

destination link]
• Story 2: User can sign into their account

destination link]
• Task: user enters email address and password [include design for page]

destination link]
• Task: user enters email address and password [include design for page]
• Task: user can click “Forgot Password” to get an email with a link to reset
their password [include design & copy for email]

Add Each Story to PivotalTracker.com
• 80%+ of engineers will be familiar with it, just use it

• Story writing guidelines:
• Each story should relate to a single, discrete feature

• Try to think of every question your engineer will have:
• Always include needed design assets (PSDs, images, screenshots,
whatever you have)

whatever you have)
• Use the “tasks” section to create checklists for the engineers to double-
check before submitting

whatever you have)
• Use the “tasks” section to create checklists for the engineers to double-
check before submitting
DO NOT assume that your vision for the product
is clear to your engineering team.

Step 2: Organize & Track Your Backlog
• The “backlog” in Pivotal Tracker is the to-do list for the
entire project

Step 2: Organize & Track Your Backlog
• The “backlog” in Pivotal Tracker is the to-do list for the
entire project
• Always keep stories ordered by priority:
• Stories that aren't dependent on any others are the highest
priority (e.g., login requires sign up, so build sign up ﬁrst)
• Engineer will start at the top and work her way down

Keep it Simple for Your Team
• Pivotal Tracker is a reference point for the project; no
need to get fancy
• Ignore the point system; not necessary for tiny teams
• Keep all ﬁles, notes, comments, etc. in each story so that the
history is in one place

Keep it Simple for Your Team
• Pivotal Tracker is a reference point for the project; no
need to get fancy
• Ignore the point system; not necessary for tiny teams
• Keep all ﬁles, notes, comments, etc. in each story so that the
history is in one place
• Simple = always available, always responsive
• Respond to any changes in the story within 1 hour
• Continually follow & update the status of each story until it is
Accepted

What Pivotal Tracker Story “States” Should Mean
Unstarted No one has begun work
Started Someone has started work
Finished Needs code review (if only 1 engineer, skip this step)
Delivered PM must review and test the feature
Accept
Story is completed in full, all requirements are met
and have been double-checked
Reject
Story not completed as requested (always leave
notes when Rejecting)

Step 3: Group Stories Into “Sprints”
• A “sprint” is a protected period of time for pre-
determined work on speciﬁc tasks

• A “sprint” is a protected period of time for pre-
determined work on speciﬁc tasks
• One week sprint = plan on Monday, ﬁnish on Friday
• Once the sprint plan has been agreed to, it cannot be changed
(this is why the sprint should only last one week)

• Sprints are organized around three crucial meetings:
• Start with a “sprint planner” on Monday

• Conduct daily standups to check in every morning

• Conduct daily standups to check in every morning
• Conclude with a “sprint review” on Friday EOD

Sprint Planner
• Meet & decide what will get done in the sprint

Sprint Planner
• Show up with all stories prioritized ahead of time

Sprint Planner
• Read each story with the engineer, starting with the highest
priority
• Make sure the engineer knows what the story means and has everything
she needs to complete it

Sprint Planner
• Read each story with the engineer, starting with the highest
priority
• Make sure the engineer knows what the story means and has everything
she needs to complete it
• Add all stories to be completed during a sprint to the
“CURRENT” column in Pivotal
• This will be your to-do list for the week: if all stories get done, you
& your team were productive

Each Day During the Sprint, PMs must:
• Conduct daily “standups”
• Each morning, everyone must meet and answer aloud:
• What did you do yesterday?
• What are you doing today?
• Are you blocked from further work by anything?

• Standups should be fast (15 mins max)

• Standups should be fast (15 mins max)
• Over-communicate: share everything, clear anything preventing
progress (“blockers”)

• Assist, answer questions, and “groom” Pivotal Tracker:
• Test the latest version of the product

• Report all bugs in Pivotal Tracker

• Accept/Reject any story within one hour after it is delivered

• Accept/Reject any story within one hour after it is delivered
• Get any needed resources: answers from partners, additional
designs, tools or libraries, passwords, etc.

Mid-Sprint DON’Ts:
• DO NOT skip stand ups
• You can’t afford to be that busy

• DO NOT change priorities or add tasks
• The point of a sprint is to agree on the deliverable and allow the
engineer to focus

• DO NOT change priorities or add tasks
• The point of a sprint is to agree on the deliverable and allow the
engineer to focus
• DO NOT ﬁnd out your engineer needs something that’s
not in the story
• All design assets (buttons, colors, fonts, screenshots, etc.) should
be attached to the story before the sprint begins

Sprint Review
• What got done? What didn't? Is the project on pace?

Sprint Review
• Keep it casual
• Friday end of day, 30 minutes max
• Often done over beers, should be fun

Sprint Review
• Keep it casual
• Friday end of day, 30 minutes max
• Often done over beers, should be fun
• Take notes for next sprint
• Organize your backlog over the weekend based on what did/
didn’t get done
• Improve your organization (you will miss things at ﬁrst; that’s OK)

Step 4: Assess Progress via Retrospectives
• “Retros” are meetings that give your team a chance to air
out any issues happening with respect to the project
• “PM is pissing me off”
• “My desk is uncomfortable”
• “I think we’ve taken on too much,” etc.

Step 4: Assess Progress via Retrospectives
• “Retros” are meetings that give your team a chance to air
out any issues happening with respect to the project
• “PM is pissing me off”
• “My desk is uncomfortable”
• “I think we’ve taken on too much,” etc.
• Do these once every two weeks at the end of the sprint

You’ll Know You Need a Retro If:
• Your project is behind

• Your team is aggressive / passive aggressive

• You’re not sure what the project goals are anymore

• You’re not sure what the project goals are anymore
!
IMPORTANT: DO NOT SKIP RETROS!

Format for Retros
• Take a “team temperature” on a scale of 1-10 (10 is
best): “how are we doing as a team?”
• Everyone on the team writes down their rating
• Review any outliers (if 2 folks are a 9 and 1 is a 6, ask the 6 why?)
• Try to come up with action items if needed

Format for Retros
• Take an individual temp
• Each person writes down, on a scale of 1-10, how they think
they're doing individually
• Review any outliers here as well, make action items

Format for Retros
• Happy/sad/meh
• Using a whiteboard or Excel sheet, make columns with headers of
:), :| and :(
• Have the team write bullet points beneath each: what is making
you smile, frown or think “meh”?
• Can be anything, from “I had great coffee” to “ofﬁce is too loud”
• Review each entry, make action items

Format for Retros
• Wrapup
• Turn any action items into stories (if it's an engineering task) or to
PM to-do lists (if it's anything else)
• Review the action items periodically to make sure they’re being
resolved

Retros Are Crucial!
• Retros can feel silly, but they’re important:
• Shouldn’t take more than an hour
• Should leave the team feeling like they’re all on the same page

Summary
image credit: http://thedoghousediaries.com/

Building is Hard
• That’s why PMs are necessary

Building is Hard
• That’s why PMs are necessary
• As a non-engineer, your sole job at ﬁrst is to organize &
manage progress

Being a PM Makes Everyone’s Life Easier
• Smart people have ﬁgured out some basic but important
procedures: agile/scrum

Being a PM Makes Everyone’s Life Easier
• Smart people have ﬁgured out some basic but important
procedures: agile/scrum
• Following them is simple once you get used to it:
• Stories & a tool to keep track of them (Pivotal Tracker)
• Sprints (planners, standups, reviews)
• Retrospectives

Be Organized & Communicate
• Amazingly simple things often undermine startups
• Projects slow down when team members don't talk
• Breakdowns in communication lead to confusion, wasted time,
frustration & ultimately business failure

• Don’t let this happen to you

• Don’t let this happen to you
Anyone who is detailed, thoughtful and has great taste
for quality products can build awesome software

Thanks for reading!
I’m happy to answer any questions:
@rustysf
(russwallace.com)
Please share on Twitter, LinkedIn, etc!
image credit: http://jimbenton.com/

How to Build Software If You Can't Write Code

More Related Content

What's hot

Similar to How to Build Software If You Can't Write Code

Recently uploaded

How to Build Software If You Can't Write Code