Managing feature requests and backlog is a challenge for any software development team faced with high expectations and limited time. This presentation shows how the team at Cognito Forms moves fast while transparently engaging with their customers to prioritize development. Through sophisticated use of Trello, the team tackles complex management challenges in a way that minimizes process overhead. The focus of this presentation though is not the tool, but the methodology they use to keep things going and keep their customers informed along the journey.
2. Know Your Audience
Do you manage feature requests?
Are your stakeholders internal or external?
Do you have more things to work on than time?
Do you need better ways to prioritize your work?
3. Know Your Presenter
I’ve been building web applications for twenty years.
I lead a team of 25 amazing web developers and
designers right here in Columbia, SC.
I write or review code and designs every day.
My passion is building stuff.
8. Step 1:
Ask For
Feedback
We started by creating a
Trello board with a list of
our own ideas for
essential missing
features
9.
10. Be
Prepared
to Listen
As you can see,
More Features
=
More Feature Requests
0
50
100
150
200
250
300
350
400
Customer Feedback
11. Never Be
Afraid to
Ask
We even asked for
feedback on our “plans”
for “paid plans”.
While we did not get as
many up-votes for this
feature as others, we
received 29 detailed
comments that
significantly shaped our
plans before release!
12. Step 2:
Triage
50% of “bugs” are
really “how to”
questions
50% of “feature
requests” are really
“how to” questions
50% of “how to”
questions end up
being “bugs” or
“feature requests”
Not all feature requests
are feature requests.
Bugs
How To
Feature
Requests
13. Track Good
Ideas
Triage incoming
feedback to find new
unique merit-worthy
suggestions or
refinements to existing
ideas.
Then add the idea to
the board and ask your
customers to up-vote
their own great idea.
14. Step 3:
Cleanup
Just like a kid’s messy
room, sometimes you
have to step back and
put things in their place.
A shelf full of
disorganized feature
requests is no different.
15. Consolidate
&
Refine
Do not delete duplicate
features, merge them to
make them better.
Step back a bit and see
how smaller ideas can
be combined into
requirements for a
larger feature.
Group features into
logical areas and be
concise with titles to
facilitate scanning.
16. Step 4:
Review &
Assess
At some point, you must
decide what to do next.
Choose wisely, because
the more features you
choose, the less you will
accomplish.
Always engage the
product development
team in the selection
process
17. Step 5:
Develop &
Promote
Identify a limited
number of features to
promote to In Progress.
Work on as little as possible
Note the lack of scroll bars
Release as often as possible
18. Track Your
Progress
Remember that what
you have already done
is much more important
than what you have not
done.
Features that are in
production are much
more valuable to your
customers than ideas.
Seeing what you have
accomplished explains
why you have not
gotten around to the
rest.
19. Communicate
Why bother releasing a
feature if no one knows
about it!
Tell your customers,
throw a party, bring out
the band, shout it from
the rooftops!
Blog posts are an excellent forum for
promoting the value of a new feature.
20. Communicate
While you may build
features to attract new
customers, you existing
customers are still your
primary audience.
Let them quickly know,
within you product, that
new features are
available, and how to
use them!
In-app messages quickly alert your customers—just
don’t be annoying with them.
21. Communicate
Email is still a great way
to communicate.
Of course you can
promote on social
media as well, but a
personalized email with
simple “calls to action”
and the opportunity to
just reply to provide
feedback is very
powerful.
Email is still relevant.
Let your customers know about new features, and Ask
For Feedback again!
22. Fluffy
Puppy?
Thus ends the fluffy
feel-good portion of this
presentation.
Managing high-level
marketable features is
fun, but it is also just the
beginning.
23. Managing
Releases
A few big ideas require
thousands of small
decisions.
Avoid getting lost in the
details, but make sure
you know the details.
Feature Boards
Release Boards
1. Backlog
2. Hotfixes 3. Feature Releases
25. Deliberate
Triage
Internal ideas, bugs,
tiny feature requests,
and random thoughts all
get sent to triage.
The team reviews these
once a week and
promotes them to
release boards or
relegates them to
backlog.
Nothing can be left in
triage—promote or die.
In the heat of battle, don’t think to too hard—just
create the card and send it to triage.
Backlog
Hotfixes
Feature Release
26. Ignore
Backlog
If it is important, it will
come up again.
If the feature is critical for
your stakeholders, they
will keep letting you
know.
Bugs are features too—
your support load will let
you know what is
important.
But don’t forget to search
your backlog before
adding new stuff.
27. 2. Hotfixes
If you release perfect
software, you took too
long making it perfect!
Avoid technology debt
by releasing early and
often, but be prepared
to work quickly to
resolve issues.
28. Hotfix
Drivers
In between feature
releases, there are
invariably surprises that
affect enough
customers to make
them important.
Hotfixes are largely
driven by issues
reported by customers
through support, as well
as proactive diagnostic
monitoring of errors and
performance.
Triage
Support
Diagnostics
29. Release
Workflow
Critical issues get
promoted to In
Progress.
As developers and
designers check in
fixes, they promote
cards to Ready for
Testing.
Staging deployments
automatically promote
cards to Testing.
Cards then cycle
through Failed Testing
or become Ready For
Release.
In Progress
Ready For Testing
Failed Testing
Ready For Release
Testing
30. Test Cases
During development,
feature cards have
requirements.
Cards promoted to
Testing must have Test
Cases.
Failures during testing
get recorded similarly.
Once all Test Cases and
Failures are resolved,
cards are promoted to
Ready For Release.
31. Release
Archiving
When hotfixes role out
to production, the entire
Ready For Release lane
moves to the Release
Archive board.
This effectively clears
out the Production
board, except for some
potential lingering In
Progress items.
Release boards should
be both clean and
temporary.
32. 3. Feature
Releases
Where the rubber meets
the road.
If you do not manage
this process correctly
you either fail to release
or wish you hadn’t.
33. Release
Boards Are
Transient
For each release we:
1. Create a brand-spanking new
release board, which is green
because it is going places.
2. Fork our product to prevent overlap
with hotfixes and the occasional
parallel feature development.
3. Put as few features as possible on
the board, and then beef them up
with requirements.
You must know when
you are done!
Avoid adding stuff along
the way, or you will find
yourself on a treadmill,
going nowhere fast.
34. Track
Progress
Include enough detail in
your release
management process to
ensure you know when
you have finished
implementing a feature.
Avoid adding
requirements to a
feature.
Consider removing
requirements to are not
essential to the feature
release.
35. Test &
Release!!!
Similar to hotfixes,
promote and test until
everything is Ready For
Release.
Then do not be afraid to
pull the trigger and
release your labor of
love to be embraced by
your customers!
Finally, archive your
release board and start
over with a clean slate.
1. Create Feature
Release From Ideas
4. Archive Everything
3. Deploy to
Production
2. Build & Test
5. Repeat
36. Recap
1. Transparently engage with your
stakeholders.
2. Release early and often.
3. Ignore backlog and stay focused.
4. Find a process that works for your
team.
37. Questions?
Always remember that
product development is
a race.
• You must push
yourself to be
competitive.
• You must pace
yourself to not burn
out.
• You are on a track,
going in circles—start
and finish lines are
arbitrary.
Good Afternoon
I am Jamie Thomas and I am cofounder of Cognito Forms, a cloud startup based right here in Columbia SC that is rethinking how to allow anyone to easily create powerful responsive beautiful forms that can actually solve complex real-world problems without compromises.
I am going to discuss with you today how we transparently manage feature requests and backlog in a way that engages our customers in a meaningful way and while still allowing our relatively small team to iterate and innovate to get stuff done.
Since this talk will be about understanding stakeholder needs and prioritizing what is important, I want to first start by understanding my stakeholders in the room—you!
Answer each of the following questions by raising your hand. If you did not raise you hand then this talk likely is not for you. If you did, then I will try to tailor the presentation to match my audience—wish me luck!
I still have my “Teach Yourself Web Publishing with HTML 3.2 in 14 Days” book by Laura Lemay, which is one of the few tech books I can say I have read cover to cover.
Google search did not work very well back then…
Since many of my examples today will be based on Cognito Forms, here is what you will see when to venture over to our product.
The key point here is that anyone can try out our product without signing up, and anyone can start building and using unlimited forms for free.
This means that we have a lot of people using our service with a wide variety of backgrounds, specific needs, languages, preferences, etc., and not all of them will become paid customers and most of them will not be web designers or developers.
We just released our paid plans yesterday morning (whew!), but we already had thousands of customers paying a percentage fee to use our Stripe-connected payment forms.
Our goal was to release early, before we were really ready to charge for our forms, and listen to our customers to shape the product.
For example, just taking a quick glance at our feature page, 13 of 19 of the features we highlight were not available when we launched at the end of 2013.
Our first goal was to get users to listen to, then figure out how to listen to them and manage expectations.
From the beginning, we wanted to try a different approach to managing feature requests.
We knew we wanted a transparent way for our customers to know what we were working on and collaborate with us on shaping the product.
We were also avid fans of Trello and used this product extensively for lightweight project tracking.
We decided, even before we launched, to make our proposed feature list public, similar to how the Trello team itself maintains a public feature board
Not all feature requests make sense, but most are reasonable.
If an idea is similar to an existing idea, try to combine as much as possible.
Whether the idea is new or existing, we always share a link to relevant features on our board and ask our customers to up-vote and comment to help us understand what they are looking for.
Many of our customers subscribe to our board or just their specific ideas so they can be notified when work on them.
Small ideas just become requirements of larger features.
Good (marketable) features have good titles because they can be easily and succinctly described.
Grouping (in this case using color labels in Trello) makes it easy to see impact areas.
Our customer suggested ideas flow into a general list.
Members of our product development team, including developers, designers, testers, infrastructure and support features by sponsoring them.
Sponsored ideas have more “meet” to them, and the sponsor acts as an advocate during team planning meetings.
After hearing pleas from sponsors and reviewing customer feedback on what’s important, the best features move into “Next Up”
This concludes the Fluffy Puppy portion of the presentation.
Before we begin discussing backlog and release management, do you have any questions or insights from your own experience?
We’ve covered the tip of the iceberg, the big picture Idea Board.
Now we can get into the nitty-gritty of release management by discussing backlog management, hotfixes, and feature releases.
In addition to our public Idea Board for big picture end user features, we have an internal board just for managing backlog.