CATALYST

Drive Digital Transformation Inside

Your Organization

The team at Postlight

Table of Contents

01 Setting the stage. 3

02 Define. Crafting the mission. 10

03 Discuss. Reaching consensus. 25

04 Develop. Building what matters. 35

05 Deliver. Creating transformation. 45

 Software is Not 

About Code
It’s about everything else. Catalyst is a framework you can use to drive positive
change in your organization through great digital work.

WE'RE POSTLIGHT BETWEEN STRATEGY AND DELIVERY

You’re reading a publication by Postlight. We're a growing global The goal of digital transformation is to drive organizational growth by
software development firm with roots in New York City. We have a lot of giving people better software tools that empower them. It's an
experience building software platforms and products. We help our important idea. But we've learned that ambitious digital strategies are
clients with digital transformation.
extremely hard to turn into working software that actually drives
organizational change.

When software challenges appear, sometimes we're the first call

someone makes — and sometimes we're the next step after a big effort That's where we come in. We shape strategies, and we build software.
collapses. But what makes Postlight special is our ability to turn a big
organizational goal with lots of stakeholders into actual, working
software that users celebrate. That's why we called this Catalyst:
Because Postlight is the catalyst that converts strategy into software.

With this handbook, you're now the Catalyst in your organization.

 “They asked if we should build our “We need something like the messaging
own CRM instead of using platform we have now but with the added
“Do you have any thoughts about our
Salesforce.” feature of actually working.”
mobile apps? I mean...we don’t have
any.”

“Our beloved CEO has decided that 15 “The official request from on high is for
years is long enough to wait between the world’s best real-time data-driven
“Do you know anything

“HEY...”
online product catalog refreshes.” online mortgage calculator.”
about digital maps?”

“We have sixty different

CMSes. Seems like a lot.”
“I think they want to move that .NET
platform to the web, if you have a free
“We need to build a community for people
six months.”
with high blood pressure that talks
straight to their tracking device.”

“They want to stand up new local sites

within a couple of hours. Also in nine
languages.”
“One word: Microservices. Well,
that’s kind of two words.”

“Apparently they sold an e-learning

platform for two million students and
right now we only have some PDFs.”
 Hey! I've got a big new digital transformation
project for you. I put some time on your
calendar for Tuesday. Very exciting!

So you’ve been given

the big task:
To build a new software product. Something modern and new to replace something
old and busted.

Look — the fact is, you're probably not building These are interesting, important tasks. They don’t get
a cool game everyone will tweet about. It's a lot of glory, but they matter. And they really do
more likely you're building a new dashboard bring positive change. But building software inside a
showing all of your company's data from the big organization is a lot different than building
last three months, or a new system for software inside a startup (or tech-first company).

managing lots of assets, or a communications

platform that lets you send status updates to Hardly anybody talks about that.
millions of people.
The Fantasy The Reality
You’re at a startup in Silicon Valley, embarking You didn’t ask for this, but now you’ve got six
on a technology mission with no baggage, no months to launch something better than the
incompatible databases, no technical debt, old system from 2006. The last person who
and no creaky legacy code.

tried to fix the problems quit four years ago.

You have tons of beanbag chairs and acres of At least five people have publicly announced
whiteboards, and you won’t use any that you will fail. But now it’s your job to define
technology older than 2019.

the product, find the budget, staff it, and get

it launched — then support it.
There’s only one way to build the next big
thing — and this is the way.

The truth is that transformation

can take place anywhere.
 Digital means change,

and not everyone

loves change

Legacy Transformation MANAGING CHANGE

When we use the word “legacy” in regular life, “Digital transformation” is a consulting term.
it’s usually in positive or eulogistic terms. It’s There are lots of concepts swirling around it,
the opposite in technology. When a manager but the big idea is to find a lot of growth by
speaks of that “legacy system” or “legacy re-organizing a whole company around digital
software,” it’s with a hint of frustration or even tools and processes — and getting rid of
shame.
legacy platforms and approaches. Can you
turn a storm window company into the next
Executives and managers in nearly every Google? No, but you can empower employees
industry are often given the same mandate: and customers by giving them Google-quality
modernize and shut down that legacy search through their entire order history and
platform. They’re asked to provide a plan, product line.

timeframe, and budget as to how they’re However, most people don’t want their lives
going to get there. And often (as often as Big, established organizations don’t love changed — even for the better — unless they
40% by some measures) they fail. change. But they do love growth — and they have some say in it.

fear losing market share (true for You have to prove that the change is good for
not-for-profits as well as the Fortune 100).
them. That you’re acting on their behalf. That you
Huge digital transformation efforts are will only be successful when they are.
Hey! We're replacing our old CRM! I need you typically disasters. We don’t have to tell you.
to talk to everyone in the company about What does work is a more grassroots
what can't change with the new one. approach — changing legacy systems that
cause people to work slowly.

ADAPTED FROM 

Upgrade: How Real Digital Transformation Happens by Postlight President Rich Ziade.
What D oesn’t Work

Let’s quickly review the most familiar patterns — the ones we see all the time
around digital transformation.

White Labels Everywhere Process Perfection Software Spackle

There are wonderful, all-in-one solutions People often advocate for a single process or Just add a few layers and APIs above your

platforms out there, and they will offer to fix approach that will fix everything. Agile legacy platform. Hooray! It sure looks modern.

every problem you have. But unless you can methodologies are great, and you should use

change your business to match up with what them.

But…now you have two legacy codebases.

they provide, they’re going to require a lot of

configuration — often just as much as custom. But a lot of times you end up with lots of code,

lots of process, and no vision.

“It’s amazing, but

Head in the Clouds D.T. .N.O.

I
you can’t use it”

There’s a lot of wisdom in moving legacy Digital transformation in name only — lots of Big software companies know the importance of

systems to modern cloud platforms — and it meetings, lots of excitement, whiteboards simple sign-on, easy account maintenance,

works and can save a lot of money! But when everywhere. And yet the big new software great tools for administrators, good analytics,

the migration is done, you still have to keep launch just got pushed out another six months .

and easy access to help desks. In-house

going. software loves to cheap out on these basics,

The word digital comes before transformation with the result being that no one ever knows

for a reason. how to log in and use the software so they just

use Google Docs instead.

EMPOWER USERS BEFORE

EMPOWERING I.T.
DEFINE, DISCUSS,
DEVELOP, DELIVER
Your digital strategy is guided by those four “d” verbs. Software is a process, and things overlap,
but you’re always doing one of these: defining the next steps, discussing it with stakeholders and
users, developing the software, or delivering it to your market.

Hey! IT is upset that you're trying to

DefinE Discuss build your own team and they're worried
What are you making?
Who will help you succeed?
you won't use the right Jira approach.
Can we have a sit-down ASAP?
Who are you making it for?
How can you help them succeed?

What superpowers does it give people?

What do they need to know to help you?

How does it help the organization?

How will you keep them informed?
Who’s going to make it?

DeveloP DELIVER
Who’s on your team?
How do we measure success for the whole project?

Do they have everything they need?

How does this fit into larger transformation goals?

How do they succeed?

What happens after launch?
What are the blockers?

How can we move faster?

Define
Crafting the mission.
 Hey! I had an idea about how to match
buyers to sellers. I was using this app called
Tinder, and...

One Sentence:
The North Star
Your first order of business is to establish the objective. Boil it down to one sentence. Put it on
the wall. You’ll need to be armed with that sentence because requirements (sometimes called
user stories, sometimes called tickets, sometimes called priority 1 needs…) are elastic. They will
change. They will drop off because of a strategic change. They will slam into a technical
limitation.

Protect the mandate. Powerful actors within the In the face of that pressure, your objective serves as a
organization will probably start to bang away at the North Star, defending this definition phase from tangents
project. They will steal favored resources. They will ask and stray ideas and suggestions. It’s nearly impossible to
for favors. That cover you were promised might start to convince a stakeholder with 10+ years of experience that
evaporate.
their idea makes no sense. Jot it down, repeat the
objective with a smile, and move on.

Solution: Stay on message about the value of

the project and the importance of seeing it
through.
Example Missions

“Project Smarter Signal will “Project Smarter Signal will “Project Smarter Signal will

increase sales by making it build connections between our make it possible for us to email

incredibly easy for our sales global team members by or text all two million of our

team to share research and making it easy for anyone in the customers about critical

news with prospective and company to find anyone else service updates within five

current clients from inside our based on their skills. People will minutes.”

sales relationship management find solutions faster by finding

software.” each other faster.”

Three things the above have in common:

They all represent big, mission-critical

goals, they’re all measurable, and they

can all be built in months.

A TEMPLATE

FOR MISSIONS

Don’t drill in on features until you define your mission. Get in a room

with a whiteboard. Fill out one of these for every type of user. Users

might be “Our boss Angela” or “People in the call center.”

For Chief Marketing Officer Angela, Project For the Community Health Project, Project
For [PERSON WITH A TASK], [PROJECT

New Signal will grant the power of Total Fast Rocket will grant the power of Super
CODE NAME] will grant the power of

Analytics Vision. Where today they have to Case Management. Where today we have
[POWER NAME]. Where today they have to

look through a lot of automated reports in to use a big set of paper forms to track our
[DO BAD, BORING THING], in the future

PDFs, in the future they will be able to constituents, in the future we will be able to
they will be able to [DO GOOD,

access a website and see a custom see everyone in one big Salesforce
INTERESTING THING].

dashboard with the reports that matter to installation that’s easy to browse.

them.

Do them for all the people involved and then do Your software should give people

them for the whole business, too. superpowers—something they couldn’t do

before. Otherwise it’s not worth doing. Excel

gives people super-math powers. Wikipedia

gives people super-knowledge powers. What

will your software do?

 Hey, I have an amazing idea for a code

Code Name name. You know I went to UMich, right? How

about Project Wolverine?

Generator
Your project needs a code name — and we’ve seen people spend way,
way too much time choosing code names. Here’s a code name
generator to get you started in seconds.

First, describe your project in two words: A verb and a

First letter of your Verb First letter of your Noun
noun. “Analyze Data.” “Internationalize Content.” “Display
Liquidity.” “Manage Cases.”

A Bright N Presto A Star N Slice

Now pick the first letter of each word. B Sharp O Smart B Jupiter O Jet

C Go P Instant C Focus P Rocket

D Ready Q Rapid D Peak Q Vision

E Smarter R Fast E Signal R Insight

F New S Crisp F Energy S Heat

G Fresh T Bold G Mountain T Victory

H Clean U Brave H Vantage U Galaxy

I Quicker V Fearless I Apex V Message

J Renew W Intrepid J Vista W Winner

K Act X Steady K Action X Meteor

L Restore Y Astute L Pinnacle Y Starlight

M Acute Z Intense M Hope Z Engine

dashboards

first Come with a list of the kinds of

data you’ll be able to gain from

You've got a code name and a mission statement. You've this new product.

even got a budget. Good enough, right? Nope. You're

missing the most important thing: real buy-in from the

Potential customers

boss.

Sources of inbound

Let’s deal with a political reality. You’ve got a new product

to build. The launch is six months away. That’s a long time

Growth by global region

for a boss to wait for results. So do this: Call a meeting. Get

a designer and a product manager. And say this:

Most popular content

“We want to do an exercise where we talk through all the

Most-purchased SKUs
Make your MoSCoW
metrics we can gather, and then design a dashboard

together that will actually help you. Because when this Now that you know what’s important to
Supply change

thing is done, it will generate a ton of data, and I see it as your boss, make a chart of features. What

my job to give you good tools to know what’s going on and

e-learning grade improvements
is:

to make better decisions based on data.”

Dataset downloads
Must have

Now work together. Whiteboard out what an “ideal

dashboard” would look like for your boss — something she

Ranges entered in the mortgage Should have

can use to make decisions and build the business.

calculator

Could have

But it serves another purpose. If you’re reading this, you

Number of white-paper downloads

care about software. Your boss — or your boss’s boss —

Won’t have

from high-density cities

doesn’t care about software. They care about productivity

and growth. Show them what that looks like in the future. Voilà! Now you have a long-term strategy
Responses to emails

And show them that dashboard as you build the platform.

for building political credibility into your

Keep reminding them: This is for you, too.

Most common help-line requests project.
A helpful clip-and-save poster from your friends at Postlight
Kidnapped By Hey I went through the PRD and added a

Consensus!
!

few do en pages. We re signed off

z ' !

IF IT’S NOT IN SERVICE OF THE MISSION, LEAVE IT OUT

Eventually it becomes time to write things down — to define the project, You’ve sacrificed flexibility and growth for near-term consensus. Your
make a plan, and codify what’s in scope and out of scope. This is the project has been kidnapped!

moment where things get real. This is the moment when things go
wrong.
How do you get a PRD that works? An experienced product manager
has to prioritize and lead. There’s no magical, points based-solution that
Here’s how it happens. You write a nice, tidy Product Requirements provides the equivalent of raw, painful experience. A product manager
Document (PRD), or Request for Proposal (RFP), or a Statement of Work should participate in and drive as much of the strategy behind an effort
(SOW). There are a lot of acronyms in our world. Either way, you send as possible. The role of a product manager in defining the product is
that document to someone else. Their team comes back with a few even more critical. A strong product manager holds the PRD — that final
ideas and tells you that you should also talk to Linus in Legal because declaration of what will be — as scripture.

he’ll have some requests.

You want a real pro tip? Distribute it as a PDF only and make people
Linus suggests that five other teams give their feedback. Before long, come to meetings to discuss with that product manager to determine
you’ve taken a simple, useful outline of work to be done and turned it what’s in and out, and when. Make opinions expensive because they
into what we call “ransom notes” — partly because they’re cobbled are.
together in different fonts and with different writing styles, and partly
because they turn everyone who works on your project into a hostage to
that document. !

ADAPTED FROM 

Write Like a Caveman, Episode #211 of the Postlight Podcast with Paul Ford, Rich Ziade, 

and Gina Trapani.
 PRD LIKE A CAVEMAN
When you need to write a PRD, don’t get formal or legalistic — go in the other
direction and write like a caveman. It’s a mental trick to help you avoid getting
fancy. Here, read this:

Sounds kind of good, right? NO! It’s bad! DANGER! It’s both too specific and too vague. It can mean anything to
anyone. And later when deadlines slip, they’ll point to it and shake their heads. How about this, instead:

Designer create design for desktop and mobile Back-end engineer build back-end

Front-end engineer build front-end

Are you handing this to your CTO? Probably not! You’ll need to professionalize it. But start with a “caveman
draft” and stick with it until it’s really, truly time to get sign off.
 The Big Ones:
Break
BreakItItUp
Up
Smaller
Smallerwins
winsfoster
fosterempathy
empathytoward Don’t
Don’tForget
ForgetAbout
AboutDefense
Defense

Money and
toward
the
theeffort.
effort.IfIfand
andwhen
whenmore
moredollars
dollars
are
areneeded,
needed,the thetone
toneofofthe
the Powerful
conversation Powerfulactors
actorswill
willinterfere
interferewith
witha a
conversationisisdifferent.
different.You’ll
You’llhave

Time
have project.
project.They
Theythink
thinkthey’re
they’reright.
right.
built
builtsupport
supportononthe theother
otherside
sideofofthe
the Product
table Product managers have to protectthe
managers have to protect the
tabletotokeep
keepgoing.
going. product from scope creep,
product from scope creep, smear smear
campaigns
campaignsand andthe
thelike.
like.Get
Getready
readytoto
defend
defendthis
thisproject
projectatatany
anytime.
time.
All IT projects are plagued by the same two budget problems:
Budgets are nearly always written before a project has been
properly scoped, and budgets are tied to an enormous,
deliverable “future state.”

Here’s how to break out: Think of your primary deliverable Scope

Scopewith
withCaution
Caution
as progress over time.

Expecting
Ex pectingRRisk
isk On our projects, we love showing prototypes as soon as
Everyone
Everyoneexpects
run
expectssoftware
softwareprojects
projectstoto
runover.
over.AndAndeveryone
everyonegets gets
humanly possible. Defend your team, but show your work. depressed
depressed when it happens.Draw
when it happens. Drawa a
MMost
ostplans
plansdon
don't'tcover
coverpitfalls
pitfallsand
and clear
contingencies clearline
linebetween
betweenselling
sellingyour
yourplan
plan
contingencies——allallofofwhich
whichshould
shouldbebe and
and drawing up the budget. Getexpert
drawing up the budget. Get expert
considered
consideredfromfromDay DayOOne.
ne.Take
Takethe
the input. Then live by it.
time input. Then live by it.
timetotoplan
planforforwhat
whatcould
couldgogowrong
wrong Beware
——andandhowhowwill
willthat
thataffect
affectthe
thebudget
budget Bewarethe
theMonolith
Monolith
and
andthe
theschedule?
schedule?
Bigger
Biggerprojects
projectsrequire
requiremore
morepeople,
people,andandcoordination
coordinationincreases
increases
asasthe size of the team does. It also means you’ll be
the size of the team does. It also means you’ll be in thein the
weeds
weedsforfortootoolong,
long,leaving
leavingthe
thelarger
largerorganization
organizationwondering
wondering
what’
what’s going on in there. And could they get your budget?Chop
s going on in there. And could they get your budget? Chop
ititup.

up.

Break
Breakupupthat
thatsingle
singleservice
serviceinto
intosmaller
smallerservices
servicesthat
thatbuild
buildonon
each
eachother.
other.Have
Havemultiple
multipleteams
teamsrunning
runningininparallel.
parallel.Your
Your
platform is the whole of these parts.
platform is the whole of these parts.
Keys to
Estimation
Estimation will never be perfect, but it can be learned. Narrow the Cone of Uncertainty
Here are some of the key practices to follow when
The more uncertain software requirements are, the more uncertain time and
scoping out your project. Also, talk to people — cost estimates to build that software will be. Certainty increases over time,
experience is a powerful teacher. as software requirements become clear. The Cone of Uncertainty is a
project management concept that you can use to rationalize a wider, less
certain estimate range. Frame your estimate certainty around where the
requirements are “in the cone.” The more decisions get made, the narrower
Make It Smaller the cone becomes, and the more accurate an estimate becomes.
An estimate is the sum of its parts. Start by reducing the task down to its
smallest pieces and estimate each. Since you’re shipping new work on at
least a weekly basis (right?), break down tasks to small pieces you can Watch Out For “Just”
show and ship quickly. To estimate those tasks, use T-shirt sizing (S, M, L,
XL), and have specific definitions attached to each size — not in hours or One software team we know set up Slack so that anytime anyone said
points, but in human-friendly units of time like “a day” or “a couple days.” “just,” a bot responded, “just.” It was a reminder: When someone says “just,”
there’s a chance they are minimizing what something entails. Train your
conservative estimation ear to hear phrases like:

Err on the Side of Overestimating

“That’ll just take a few minutes” “Just write a script”
Optimism is natural. It’s also often fatal. Just remember: The success state
is on time, and the failure state is late. When in doubt, overestimate. The
risk of overestimating your project is smaller than the risk of
underestimating. If you overestimate? Worst-case scenario is that the work “Just cache it” “Just create a batch process”
expands to fill the time you allocated to it, and you spend the money and
effort you planned to anyway. If you underestimate, you risk shipping late
and over budget, which can directly affect the health of your business.
“Let’s just try it”

ADAPTED FROM 

Estimation Is a Core Competency by G ina Trapani, Managing Partner.
BACK UP ESTIMATION
WITH RESEARCH
When someone asks you how long something will take, don’t immediately
respond with your top-of-mind hunch. No matter how experienced you are,
every software task is unique, so take a beat and say, “Let me do a little bit of
research and let you know.” Here are three research methods that always work.

Talk to engineers, designers, and anyone else A time-boxed spike

If anyone on your team or in your network has built something similar or has If you’re not sure a particular implementation will work, set a timer for 30 or
experience in an area you don’t, ask for their thoughts, or what they learned 60 minutes and have your team throw together a quick-and-dirty prototype.
in their work. You’ll be surprised at how productive a quick chat with Get them to code the simplest and smallest thing possible to see if you’re
another engineer can be. on the right track.

Talk it out Get a quote

Talk it through with another engineer. “I think it will take three months. This is cheating, and maybe we shouldn't tell you this, but you can describe
Here’s my breakdown.” This can increase the accuracy of your estimate and your challenges in a half-hour phone call and ask for a “back of envelope
spread good practices around building rationale behind estimates within and typical price range.” Make sure to tell them you don’t want a full
your team. proposal and that you’re just exploring options. They’ll send you a quick
project outline and a budget in a few days. Maybe you’ll hire them! We can
always hope.
 Impact versus 
 Now that you know every feature's value and level of effort, it's
time to prioritize.

Hey! I know we agreed not to do dark

mode, but our competitor just launched

EfforT Chart impact against effort — and optimize for the bottom right
quadrant. Sample chart below.
it, and, well, I have some news.

Multiple

Single
 Email
 Slack
 Languages
Sign On Notifications Integration
Native

Facebook
 Mobile Apps
Integration
EFFORT

Make the
 Offline


Logo Bigger Support
Change

Theming Default
 Very Granular
 Dark Mode
Sort Order User Permissions

IMPACT
Timeline Overview This is a sample timeline for inspiration — the template we
use at Postlight for many of our proposals. The most
important thing: Think in six-week phases.

box rocket
Proof of concept Alpha Beta Release

Product
Activities Activities Activities Activities
Materials Review
User Stories
User Stories
User Stories

Management Stakeholder Interviews

Design & Engineering Design & Engineering Design & Engineering
User Research Management Management Management
Deliverables
Timeline & Project Plan

Product Brief

Prioritized Feature Backlog

Content
Activities Activities Activities Activities
Materials Review
Design Updates to Existing Tests
Engineering Support
Engineering Support

StrategY Stakeholder Interviews

Patent Dashboard Design

User Research New Test Design

Deliverables
Development-ready Design
Handoff

Product
Activities Activities Activities Activities
Materials Review
Design Updates to Existing Tests
Engineering Support
Engineering Support

Design Stakeholder Interviews

Patent Dashboard Design

User Research New Test Design

Deliverables
Development-ready Design
Handoff

Engineering Activities Activities Activities Activities

Architecture Review
Design Updates to Existing Tests
DevOps & Deployment Add and Update Tests

DevOps Scaffolding Patent Dashboard Design

Architecture
Configure APIs

New Test Design Implement Technical Architecture Front End Updates

Deliverables Deliverables Data Export & Notifications

Development-ready Design Beta Release Deliverables
Handoff Launch
 FAILURE IS LATE

OVERESTIMATE!

A helpful clip-and-save poster from your friends at Postlight

Discuss
Reaching consensus.
The People on the
B.U.S.
Software always involves three kinds of people:

Builders: The people who will make the software. Designers

and Engineers (front-end, mobile, and back-end) led by
Product Managers.

Users: The people who will use the software every hour, day,
week, etc. They can be divided into Admin Users, who run
and manage the software, and End Users.

Stakeholders: The people who decide if your project gets

funded and determine its success — and your success. Your
boss, your boss’s boss, the CTO or CIO, or even the CEO.
 Meet the
Builders
Let’s start with the builders — the people you need on your team to make your
product a reality. The best time to build a productive sotware team was 18
months ago. The next best time is right now.

Front-end/Mobile

Product Managers Designers Back-end Engineers

Engineers

What they’ll be Advocating for the users Iteratively building full user Writing code that glues Writing/styling
doing
and managing the project journeys that show every together multiple APIs and components that "talk" to
screen
data sources into one API APIs.

Greatest fear
No one sees how valuable Being asked to code
“We’ll just move everything “It doesn’t work on the
they are to Salesforce” on month five CEO’s son’s phone.”
of the six-month project

Most secret hope #1 in the app stores

Being invited back to their Recruited to work at a Invited to showcase at
alma mater to teach
billion-dollar web analytics Apple WWDC

company

Next career step

Larger efforts, larger Building design systems for Building big APIs for use by Moving a complex
budgets, multiple teams whole product families the public
software-as-a-service
product to mobile

Digital Product managers are not project

Leadership is
managers.
A product manager understands and internalizes the motivations,

Product
rationale, and domain in which a product lives. Yes, there’s the
usual amount of traffic-copping that would be required by a big

Management
project. But the key distinction is that a good product manager
winces when a decision is made that strays from the mandate.

They don’t just stick to the schedule. They

Your project needs a product manager. It’s a critical hire and a challenging one. You need stick with the vision.
someone who will get their hands dirty, understands the platform, and can coordinate
between designers and engineers.

Advocacy is key. Hard decisions will have to be made. When

change comes (and it will), a product manager instinctively
At Postlight we look for someone who will “inspect the element” — who will drill in on drives decisions in the best interest of the product. And they
technical details in order to figure out what’s going right or wrong. keep going.
The Six Big Mistakes
of Product
Management
Being vague about your timeline and Waiting too long to ship. Show people Neglecting your tooling. Groups need good
commitments. Tell people exactly what’s something they can use within weeks. tools for communication, sharing design, and
happening and when. And then make it Otherwise you’ve created a vacuum that deploying code. If your company has
happen. Don’t overpromise. people can fill with expectations. old-school IT, you will ship old-school
products. Build a new stack.

Forgetting to market your product internally, Single-sourcing your QA (or not doing it at Listening to your customers verbatim. What
too. Just launching code is not enough. You all). QA is not something you outsource. It’s people ask for isn’t what they want — which
need a marketing plan to share progress and something everyone needs to be doing at goes for your boss, too. Your job is to figure
features and to help people understand what’s every level. Automate what you can, and then out what will make their lives better and
in it for them. accept that quality has nothing to do with empower them and give them that. What they
passing QA tests and everything to do with need is different than exactly what they ask
results. Your team needs to take ownership — for.
otherwise, don’t bother.

ADAPTED FROM 

6 Mistakes Your Product Team Is Making — and How to Fix Them by Chris LoSacco, Managing
Partner.
BUILD SMALL TEAMS OF Hey! My cousin is currently walking dogs,
but he likes to make web pages. I think

GOOD BUILDERS he'd be a great fit.

Start with a team of four:

Good builders are deeply empathetic. Good builders are also occasionally
This one is obvious: Great builders unempathetic. Users defend bad habits
internalize the needs and challenges of because they’re familiar. Great products
Product manager, designer, their users. But also… introduce new ways of doing things that people
back-end engineer, and front-end want to embrace because they’re obviously
engineer. Then, stop there! That’s better.

enough people to ship a meaningful Good builders push some of the limits. Yet Good builders eliminate steps. “Let’s get rid of
digital product to the market in six they also propose solutions that go beyond it and see what happens…”. Good builders are
months. More people might feel like conventions and what is “allowed.” Usually willing to take the risk and throw that widget
this leads to pushback from business out. Rather than solving every need with yet
more impact — but bigger teams
stakeholders (too costly) or from peers (too another button or lever or setting, they
create new dependencies and raise complicated). But, a good builder chooses constantly seek to simplify things further.
expectations.

these battles wisely, and their passion and

advocacy for the user can sometimes lead
to an exceptional outcome.
It’s better to have multiple small
teams than one big one.
Meet Your
Users
How do you log in? · What do you usually do first? · How
do you find things? · How do you add data to the
system? · Do you do a lot of cut-and-pasting? What
takes you the longest? · What goes the fastest? · Do
things ever break? · What happens then? Who fixes
No really, meet with your prospective users. Product them? · What do you do to edit something? · What
managers and other team members need to sit down and happens when you make a mistake or typo? · Who takes
watch them work. A half hour at a time is good, but longer over when you’re out for a day? · Is this better than it
used to be? · Has it been getting faster or slower? · Who
is better. Ask them how they log in. Ask them where things else works in this system with you? · Who taught you
slow down.

how to use this system? · Is there any documentation? ·

What would make things go faster? · What do other
people complain about the most? · If you could wave a
Never defend anything. Never explain anything. Just let wand, what would this do? · Are there any other tools
them talk, and encourage them to keep going, even if you you’d prefer to use? · Do you need to save or does it save
can explain why things are the way they are.

for you? · Has it ever cost you time?

Just...listen.
 ! '
The Two Kinds of
Hey We d love to get a demo before we

decide on ne x '
t year s budget, maybe in

the ne xt half hour ?

StakeholderS

Manage up! Software projects are abstract. If your boss’s boss doesn’t

know what you’re doing, it’ll be easy to cut your project — and possibly

your job.

Détente Stakeholders DREAMER STAKEHOLDERS

For the détente stakeholder, software is neither enemy nor ally. Keeping the peace is success. This is a more unusual type. The dreamer

Diplomacy is always better than military maneuvering. Doing less means less of a chance of sunk costs stakeholder views software very differently.

and misinformed adventures that lead to apps nobody uses. A handful of motivators drive détente With an eye toward competitive advantage

stakeholders: and driven by innovation, dreamers see

latent opportunity in software. Rather than

Mitigating risk. There are certain nightmare scenarios that haunt business leaders. Your viewing it as an opposing superpower,

technology infrastructure melting down is one of them. Whether through egregious error or software is part of their own arsenal for

malicious attack, CTOs around the world spend a lot of time investing in stabilizing and protecting succeeding.

their platforms. It’s boring and uninspiring but very necessary.

Dreamers sound dreamy — but they bring

Ensuring stability. Inventory management. HR systems. CRMs. They just need to work reliably. The risk, too. They have big platform visions and

latest Salesforce features are nice and all, but the most critical feature is stability. This isn’t limited when that first, awful version of the software

to software running reliably. Too much change can create instability in terms of processes and launches, they might freak out a little.

friction around re-educating users. Change is scary.

Prepare them for a journey with lots of steps

and promise that you’ll always keep the big

Competitive pressure. Competition is little more than a nuisance for the détente stakeholder. goal in mind.

Things are rolling just fine and before you know it, the bank across the street releases an app that

lets you deposit checks by taking pictures on your phone. Détente stakeholders don’t care for

change. But business is business, and when the CEO calls you in asking what you’re doing about

depositing checks on mobile phones, you need to be ready with a plan.

ADAPTED FROM 


The Dreamer and the Diplomat: Who Buys Software for Your Business? by Rich Ziade, President.
Ones to Watch Not everybody will be rooting for your
success. Here’s what to expect and how to

Out For manage it. Keep smiling and look sharp!

Troublemaker How they wreck you What you can do

Naysayers It doesn’t matter how attractive your project is. It still represents a Bet you think we’ll tell you to build consensus. And sure, seek input.

transformation of how things are done today, and that means a But don’t waste valuable cycles trying to win their love. Smile and

higher level of risk. That makes lots of people nervous. The loftier keep going. You might think you should win them over, but you

and more disruptive your vision, the more people will plant seeds of probably can’t. And when you start to see success, offer to share it

scrutiny and doubt. with them and give them credit for keeping you on your toes.

Incumbents Your organization has cultivated talent and skills that are optimized Empathy goes a long way here. These people are scared. The
for the way things work today. Your project represents an project you’re doing might bring them a lot of risk. So bring them
existential threat to the systems and logistics those people control. with you. Show them what’s next, ask their opinion, and give them
You’re building the assembly robot in the factory, and no one wants input. Sometimes you really do represent risk — as in, if your project
to lose their spot on the line. works, their jobs will change or disappear. In that case, be
respectful but keep going.

Platformers Doing anything custom means that at any time someone can swoop Listen, they have a point. You have a duty to button this up, know
in and go, “Why don’t we just use—” and mention some big platform the market, and have a good reason for doing things your way. “We
or brand name like Salesforce, Oracle, Microsoft Dynamics, and so looked very closely at Salesforce, but it brought a lot of complexity
forth. Then your boss turns to you and goes, “Yeah, why don’t we?” and ultimately we found that modifying it was going to cost a lot
more, it wouldn’t give us a flexible API for new product
development, and it wouldn’t meet the content management
requirements from the leadership team.”

Boss’s Boss Despite sign-offs and an approved budget, decision-makers above Build bridges now. Ask for regular check-ins. Explain your cadence.
you will apply their own pressure. They need results, and anxiety is Show them the designs way before launch. Get to know their
inevitable. In that context, any missed milestones, however teams. Teach them to ask for what they want early and show that
reasonable in the scope of the work, will raise everyone’s stress you’ll get it. Don’t pretend this time is different or that they would
levels. never swoop in. It can’t be stopped, only managed.
 IS JUST

NEWS

A helpful clip-and-save poster from your friends at Postlight

DEvelop
Building what matters.

B.U.S. Stops: Your

Two-week Loop
Work has started. Your job now is to fully inform everyone about your project —
every two weeks. Every two weeks...

Meet with Builders Meet with Users Meet with Stakeholders

Define What components must be in this system? What’s broken with your current experience? What components must be in this system?
What platforms and tools already exist to What would make your life better? What What platforms and tools already exist to
help us move faster? What can we avoid would make things faster? help us move faster? What can we avoid
doing? doing?

Discuss How’s it going? What risks do we see overall? What would make you more productive at How’s it going? What risks do we see overall?
What are you learning from users? How are your job? What tools exist in the world that What are you learning from users? How are
you getting along? What vision do you each you cannot use today? you getting along? What vision do you each
have for this project? have for this project?

Develop How is our process working? How are we Can I show you something? It’s rough, but I’d How is our process working? How are we
tracking issues? Are there conflicts we can love your feedback. tracking issues? Are there conflicts we can
unblock, personal or otherwise? unblock, personal or otherwise?

Deliver What’s our plan after launch? How can we What’s our plan after launch? How can we
maintain and extend this product going Did we solve
maintain and extend this product going
forward — and is this the right team for that? forward — and is this the right team for that?

your problem?
(Same as for the Builders!)
Mountainsides
This diagram shows how we see projects at Postlight. The "mountainsides" are a clear
declaration that a software development effort — all the way from conception to launch — is a
messy endeavor where things blur together and overlap. Only once you acknowledge and
embrace that chaos can you tap into the great talent in your team.

Strategy Product Design Platform ArchitecturE Software Engineering

Product Management
Product Design
Platform Architecture
Software Engineering

Competitive and User Research

User-Experience Design
Data Architecture
API Development

Requirements Analysis
Information Architecture
Product Architecture Content Management

Product Strategy Web Design

Web Development

Mobile App Design Mobile App Development

CLIMBING THE
MOUNTAINSIDES
Assume overlap between individuals, ideas, and phases. If things aren't a little messy, you're not
moving fast enough.

No boxes. Instead we have peaks and valleys. Skills and capabilities are not Embracing overlap. We don’t believe in “phases” in the traditional sense. Nor
switches you can turn on or off. Early on, product strategy dominates. Design do we believe in discrete walled-off teams. Notice that product strategy and
is in the room, and as the strategy comes into focus, design heats up. design layers linger throughout the effort — together. Designers talk to
Architecture engages and joins the conversation as design is turning a corner engineers. Architects talk to product. It’s highly collaborative by design.
and artifacts are firming up. Finally engineering takes the wheel with all the
other disciplines nearby.

Product and design are in the mix. Most software methodologies like Agile It’s not the real plan. This diagram is not the actual project plan for any
don’t talk much about product and design. The focus is mostly on the particular project. It’s conceptual. We don’t presume to be able to draw out
engineering. We’ve found that on successful projects, product and design exact phases and timeframes when we haven’t started working yet. Anyone
heat up early and never really leave. The owners of the experience visit the who bothers to do so at this phase is just creating filler.
work site constantly, hardhats and all.
RELEASE
Hey! When are we going to see the new

mobile app? A lot of people are wondering.

EARLY!

There is no more powerful political tool than releasing good software into people’s

hands. You’ll find that the burden of consensus-building and campaigning is far

lighter because the thing speaks for itself. It’s something you can draft behind to

keep going.

Set expectations early. Tell everyone, not just your key Aim small(er). It’s a big endeavor that’ll take years. Carve

stakeholders, when they’re going to have something in out that minimum valuable product. What can make the

their hands to play with. Don’t share a 7-layer-cake Gantt biggest impact in that tight timeframe that you’ve

chart with milestones. Just tell them when they’re going established? What hurts the most for users? Oftentimes

to get something to touch and use.

the bar isn’t that high. Stay away from the edge cases.

Don’t wait too long. If you’re holed up in the factory for Make a good product. At the risk of restating the obvious,

too long, people will start to wonder what’s going on. This release a tight product the first go-round. It should feel

will happen even if you didn’t miss your dates. Release snappy and intuitive to use. You’re going to make

something sooner. Pick a timeframe and prioritize changes, but aim to leave an impression of something

requirements around what you can pull off in that first solid and of quality in people’s hands.

cut. Ship something.

 50
Speed Traps
Four things that will slow you down.

Backlog-driven development Coattail Riders Too Much Process

Most of the time, enterprise software (which is Things are going great and we’re close to If they’re talking about agile, if they’re moving
susceptible to the winds of big clients asking for launch! That’s why we need to make sure that cards around, if they’re talking about
random things) is little more than a bizarre pile the new product integrates with the new CRM microservices and platform architecture, if there
of features, jammed in so you can check those system that’s just now coming online. Then isn’t code getting checked in, you’ve got
boxes in Jira. The product’s roadmap is little everything can be new! Obviously this adds six process creep. All the regular rules apply about
more than all those features plotted out across months to your roadmap, but you don’t want to perfect being the enemy of good, but it’s usually
time. That’s how you end up with big, layered, let the sales team down, do you? Smile, nod, not the result of laziness. It’s the result of fear
awful software. Declare backlog bankruptcy. It’s agree violently, and insist that this is absolutely and confusion—fear they won’t be respected,
better than doing bad work. your first priority once you launch. And maybe it confusion about what’s being built.
will be!

Brandomization
Brands and rebrands are serious endeavors that
guide a ton of product decisions. Always, always
do the brand first, work out your identity and
values, and only then update your digital
products. Otherwise you’ll start them both and
then have to redo the digital product with the
new brand.
AcceleratorS
Four things that will speed you up.

Bank your wins Speak your stakeholder’s

language
Focus on the Minimum Valuable Product. What
can you put in people’s hands, and how soon No one cares how software is made (well, we
can you do it? Nothing is more powerful at do, but not normal people). They care about Share ownership
creating organizational change than working their employees, their careers, and their targets.
software. Learn how to see the world like them, and use Start crediting other people for your wins. Thank
the terms they use. Make sure that they’re the users, thank the bosses, thank the team.
hearing about strategic goals, key metrics, and Make up reasons to thank them. Thank
seeing progress on their dashboard, not hearing everyone, including your bosses. Create a giant
about tickets squashed or lines of code. success train that they want to ride.

Tell a good story

It’s absolutely essential you don’t go silent. Keep
talking to all stakeholders, every two weeks.
Share screenshots. Otherwise they’ll imagine
things, and it won’t be good for you.
There’s no
going back
Hiring a team for any reason is hard. Hiring in technology As we write, many people are working from home. But
is incredibly, famously hard, even with all the perks big eventually we'll be back in the office. And that's when
tech companies can offer. Hiring for an initiative inside things will get tricky.
your company is even harder.
So when you do it, if you want to succeed, you have to tell them there’s no
Wall Yourself Off...Literally
going back. If team members are recruited onto a project, tell them they’ve If at all possible, separate the team from the usual work environment. At
lost their former jobs. Define new roles and titles. They should recognize the very least, group team members close to one another. Ideally, there’s
this as a separate listing for their LinkedIn.
an environment with pseudo-borders that represents HQ. Even masking
tape on the floor can help! But if you can, leave the building and find
Most importantly, communicate to their former managers that those another address. Ask your vendors if you can stash a team at their
employees are no longer available at their previous role. They can’t be offices. Be creative. It’s not forever.

hijacked, or brought back to their old roles to “advise.” Make sure leaders
know they will need to replace the staff you’ve recruited, as early as It’s not just about protecting the team and making sure they’re focused.
possible.
People don’t believe change is possible in big organizations. They talk
about it in the elevator, and that rubs off on everyone. Your job is to
Expect some people to be annoyed. You’re putting your project’s needs over transform some part of the business—and you can! But not if your team is
their needs. You’re telling them that this is your direct report now, and hearing over and over, with every bite of taco on Tuesday, that it’s
they’d better back off. Not every manager takes that well — and in fact, pointless to try.

most don’t. But have faith and stick to your guns. They’ll get over it and
move on. Bonus idea: If real estate is tricky, people can go remote four days a week.
Going Outside
Considering the challenges of hiring and the pressure of deadlines, many
companies simply hire an outside vendor. There are benefits to this approach, and
we say that not simply because we’re an outside vendor.

Because the team is new, there’s no baggage or history to contend with. You’re
getting a startup group for hire, motivated to deliver constantly (or get fired).

That said, you may meet internal resistance. If Get out of the black box. When work is taking place offsite, it can
you do decide to hire an outside firm to carry the feel as if a project is in a dead zone. Find a way to show progress
project forward, here’s what to expect from your and prototypes as early and often as possible to build trust. Don’t let
own team:
silence breed distrust.

“Why not us?” Often from the same people who They need allies—that's you. Defend them inside your org and don't
told you that you couldn’t have an internal team. let people pepper them with meeting requests. They aren't in a
People might feel slighted or ignored and react position to say no, so control access. Be a gatekeeper. Otherwise,
by sowing resentment.
people will burn through your budget and you'll have less to show.

It’s tricky terrain to navigate, but very necessary.

Overcommunicate the rationale for hiring an
outside group.
How Agencies
Get Your Number
Obviously we believe that outside vendors are a great solution. Hey! Do you know any good
But we want to keep ourselves accountable, too. As an agency, agencies?
you get to see a lot of other agencies at work. Here’s what we’ve
learned.
They charge you to keep digging
They sell zero, (or infinite) maintenance

They come in with a cheap initial bid and underbid their competitors. A few No matter what happens, you need a day two, post-launch plan for
months goes by. Progress slows down and new requests show up to fill the maintaining and improving your platform. Some firms pretend they’ll deliver
silence. “Well, this wasn’t in the agreement,” they tell you. “We’ll put together perfection in order to get you to sign. Some offer to set up a team that will
a change order.” Welcome to your next year of hell. Good consultancies share never leave you, so they can charge forever. Good agencies help you figure
real costs up front.

out the smallest possible post-launch team to support your new platform.

They add specialists

They sell platform services

“You need a senior solutions architect.” “You need a marketing content Most agencies have a platform that provides their bread-and-butter. It might
strategist.” Do you really? How come? The more titles you see, the more be Drupal, WordPress, Shopify, Sitecore, Salesforce, or any other of hundreds
suspicious you should get. Good agencies bring you a strong leader who of solutions. These solutions are great, but they definitely turn every problem
helps you plan.

into a platform-shaped nail. Good agencies give you platform options and
explain the pros and cons of each.
They use word salad

Listen for words like "microservices" or terms like "experience architecture"

which require "experience architects." Watch out for exciting-sounding terms
and acronyms like "blockchain," "AI," and "ML," used as miracle cures. Good
agencies explain in simple terms.
Deliver
Creating transformation.

QORE Success
At Postlight, we evaluate every effort every two weeks using our QORE
framework. These are tough meetings where people put egos aside and work is
reviewed without much mercy. QORE isn’t just a simple acronym for us: It
represents what we believe about software. We might ask...

Quality Opportunity
Is the code and design of the highest quality? Are What opportunities do we have to improve our level
gaps understood and being addressed? How does it of service and grow the utility of this software? Do
compare to where we were two weeks ago? Does we need help from others? Is there a marketing plan,
the product vision still make sense given what we internal and external, in place? Could other teams be
have learned? Will this product engage its users? using it today, and if so, how can we find them and
introduce them to this product? Could leaders share
our progress in public to create momentum and
show how we are smart and forward-thinking?

Risks Efficiency
Where are blockers emerging? Are team members What could be done faster? Where is the process
pulling tickets or actively engaged? Will this product causing friction? What external dependencies are
succeed in its market? What competitors could slowing us down? What parts of the system could
emerge? How will this product live inside the larger we replace? What could we avoid building? How long
corporate IT governance structure of its host? What are bugs and issues remaining in the queue before
will happen when bugs are found after launch? Will being triaged? How long before fixes are in place?
the core platform scale?

ADAPTED FROM 

QORE: On Postlight’s Secret Recipe For Project Management by episode #236 of the Postlight
Podcast with Paul Ford and Rich Ziade.
Quality
Assured
QA is usually outsourced or shipped over to a team. The problem is check
that this leads to a culture of teams throwing things over the wall to
QA and waiting for results, while QA turn into pseudo product check
managers finding bugs.

What needs to happen is simple: Your entire team needs to be responsible for quality. check
Product managers need to test and debug. Designers need to advocate for their designs

check
and adapt them when requirements shift.

Engineers need to practice both automated testing and also understand that success
comes when their code has fewer defects. We believe pretty firmly that when the history
of software is written, the idea that you could totally outsource QA will be seen as a
historical curiosity, like punched cards and floppy drives.
 Comes
Transformation

A helpful clip-and-save poster from your friends at Postlight

 STEP BACK FROM THE BACKLOG

We’ve discussed this before, but now it gets serious. You’ve “shipped”,
which can mean you’re in “maintenance mode.” It’s a polite fiction. There’s
always lots left to do. And “backlog” is a dangerous term. It implies being

After Launch: A Plan

behind. It also implies that what you’ve got today is an incomplete thing.
You need to get through that backlog. It implies that the product is done
iterating and growing and playing catch-up with bugs. The good times are

for Stewardship over.

If you zoom in on a backlog, you often find discrete features in the form of
tickets or user stories. They originate from all sorts of places:
Driving the project forward demands strong stewardship. As
the light at the end of the tunnel finally glimmers, things get
A key client wants a feature and their renewal is coming up.

harder. Designing and building gives way to infrastructure

considerations and DevOps. As you get close to launch, there’s Customer service is seeing a pattern and it’s time to address
a particular issue.

a sense of diminishing control for both business and product.

An executive has an idea and blasts that Sunday email.

Still, strong product management sticks around until launch. Usage data is showing a pattern that can be improved.

There is no better last mile advocate than the product

A competitor has that feature and it’s time to catch up.
manager that defined and internalized the mission of the
product. That last step can be a drag, but you haven’t
launched until you launch. The key thing to remember is: Big backlogs are signs of success! When
any piece of software makes it out into the world, inevitably feedback
follows. The bigger the impact of the software, the louder and more
varied the feedback. But that doesn’t mean you’re beholden to them...
Is This Transformation?
A great product leader pauses and steps back. They are concerned about—and defending—the
overall integrity of the product. Yes, that request is reasonable, but how do I solve this problem
without compromising the experience? Is there something more fundamental to address here?
What’s really at issue?

It’s often hard to ask these questions. They require time and But believe it: Stepping back is true product
understanding from your stakeholders. You don’t often get either. advocacy. It’s how you get good work done.
Instead, you’re pressured to “get the feature in.” Great product leaders And in the end, that’s what everyone is after.
hear that feedback and think holistically and creatively to solve those Great product.
problems. (We use the QORE framework to push through this. We’re
looking for quality and results first, then we can talk metrics.)
 CHEAT sheet

Here it is, all of Catalyst on one page. The simplest possible guide for managing

complex software projects. Just remember — "6 × 2 × 4 × QORE" and you've got

things well in hand.

If your digital team is telling you why

they can’t build something, send us an

Set a 6-month goal. “In six months we are Then every two weeks measure your
email at [email protected] and
6 going to launch a new product that achieves progress using QORE:
ask for a call.

[key goal].”

We’ll set up a conversation with Postlight

Quality. Are we managing the complexity
leadership and we’ll explain how we’ve
while delivering simplicity?

Set a 2-week cadence. “Every two weeks we

applied the concepts in this deck to
2 are going to ship something useful to
Opportunity. How could we help people huge matrixed organizations like

someone we know.”
more, or help more people, with what we’re Goldman Sachs and the NYC MTA.

building?

You won’t be talking to sales. We don’t

Continually do 4 things that start with D:
Risks. What are the three things that could You’ll
4
have a sales team. talk to members

break?
of our digital strategy team. We’ll give

Define what you’re building (both the you advice based on experience

whole thing and the next two weeks).

Efficiency. What could we not build in order

to go faster?

Discuss it with everyone involved,

including builders, users, and

stakeholders.

Ship in sixes:

Develop and build new features and

Pre-alpha in 6 weeks

components.

Alpha in 12 weeks

Deliver what you built to real users and

get their feedback. Beta in 18 weeks

General release in 24 weeks

PERMISSION GRANTED Hey! I just wanted to say...great job!

Many of our clients come to us seeking permission: permission to make the system work, to
value their user’s time, to care about design and quality in ways that never get captured by a
bunch of issues in a ticketing system.

Permission granted. Put your users first and cut down on cost and waste. You don’t have to
throw away the past. You can put it to use.

In fact, this isn’t just permission. It’s a mandate:

Leave your mark.

make things better.
WE THE︎WORK
Postlight is a team of people who love building software. We’re fans
of big legacy codebases, complicated platforms, and products with
tons of requirements. We pride ourselves on being “shaped to ship.”
We will help you get your project done and on schedule, come hell,
high water, or anything in between.

Get in touch.

[email protected]