The document discusses challenges faced by Opower, a software company, in managing knowledge as it experiences rapid growth. As Opower hires more employees and develops new products, its wiki has become overwhelmed, leading users to feel there is too much or outdated information. The speaker recommends treating the wiki like a product by identifying root causes through stakeholder interviews, metrics, usability testing, and question tracking. Initial findings revealed frustrations with credibility and accessibility of information, as well as critical needs around product limitations. Solving scaling problems requires understanding usage and pain points.

1. 8 November 2013
Cura%ng
Content:
Designing
Wiki
Solu%ons
that
Scale
Rebecca
Glassman
Opower
Product
Documenta6on
Manager

2. Opower
• So9ware
company
that
partners
with
u%li%es
that
want
to
help
their
customers
save
energy
• 6
minutes
• Mo%vate
people
to
pay
a?en%on
and
change
their
behavior

3. 3
Terawa?s
Saved
$325,000,000+

4. Products
• Printed
Home
Energy
Reports
• Email
Reports
• Web,
Mobile,
and
Thermostat
Apps
• Alerts
• Many
more!

5. Opower
Product
Docs
• Audiences
– Opower
employees
– U%li%es
– U%lity
customers
• Deliverables
– Confluence
knowledge
base
– Online
help
– API
guides
– Many
more!

6. The Best Laid Plans…
8 November 2013
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
6

7. One
month
100,000+
views
8 November 2013
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
7

8. =
121,000
Page
Views

9. The Best Laid Plans…
8 November 2013
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
9

10. 25,000+
Pages
600+
Month
8 November 2013
OPOWER CONFIDENTIAL: DO NOT DISTRIBUTE
10

11. Hyper-­‐growth
is
a
hyper-­‐problem
for
knowledge
management.

12. Opower
at
Scale
• Hiring
and
onboarding
constantly
• Mul%ple
product
lines
• Itera%ve
development
• Interna%onal
clients
and
offices
• Specialized
teams

13. Knowledge
management
enables
hyper-­‐growth.

14. • Symptoms
of
scaling
problems
• How
you
can
uncover
root
causes
• Real
solu%ons
to
solve
similar
problems

15. • Symptoms
of
scaling
problems
• How
you
can
uncover
root
causes
• Real
solu%ons
to
solve
similar
problems

16. • Symptoms
of
scaling
problems
• How
you
can
uncover
root
causes
• Real
solu%ons
to
solve
similar
problems

17. You
might
have
a
scaling
problem
if…
you
get
the
bad
wiki
buzz.
Can’t
find
what
I
need
Search
doesn’t
work
Missing
informa%on

18. You
might
have
a
scaling
problem
if…
you
get
the
bad
wiki
buzz.
Too
much
informa%on
Can’t
find
what
I
need
Old
informa%on
Search
doesn’t
work
Keep
ge`ng
lost
Missing
informa%on

19. You
might
have
a
scaling
problem
if…
you
get
the
bad
wiki
buzz.
Don’t
understand
how
ranking
works
Too
much
informa%on
Can’t
find
what
I
need
Duplicate
informa%on
Old
informa%on
Search
doesn’t
work
Keep
ge`ng
lost
Missing
informa%on
Don’t
know
if
it’s
current
Don’t
know
where
to
start

20. You
might
have
a
scaling
problem
if…
people
start
hoarding
informa%on.
“I’m
going
to
save
this
informa%on
in
a
Google
Doc,
so
I
know
I
can
get
to
it
later.”

21. You
might
have
a
scaling
problem
if…
people
request
new
knowledge
sharing
tools.
“I
can’t
find
anything
on
the
wiki.
Let’s
buy
another
tool
instead.”

22. Too
Many
Tools

23. You
might
have
a
scaling
problem
if…
major
influx
of
product
ques%ons.
“I’m
not
sure
if
this
is
current.
I’m
going
to
check
with
the
Product
Manager.”

24. You
might
have
a
scaling
problem
if…
people
start
making
more
mistakes.
“I
didn’t
know
I
could
only
sell
that
feature
in
the
US.
It
didn’t
say
so
on
the
wiki
page.”

25. Manage
your
wiki
like
a
product.

26. Unearth
Root
Causes
1. Stakeholder
interviews
2. Metrics
3. Usability
tes%ng
4. Ques%on
tracking
5. Knowledge
mapping

27. Interviews:
Groups
• Different
roles
• New
hires
and
experienced
• Tech
and
non-­‐tech
• Browsers
and
contributors
• Management

28. Interviews:
Ques%ons
• How
o9en
do
you
use
the
wiki?
• What
frustrates
you
about
the
wiki?
• What
other
systems
of
record
do
you
use?
• What
are
the
five
most
important
things
your
team
needs
on
the
wiki?

29. Interviews:
Results
• Frequency
of
use:
varied
by
group
• Frustra%ons:
credibility
and
accessibility
• Other
systems:
too
many
• Cri%cal
content:
product
limita%ons

30. Metrics:
Google
Analy%cs

31. More
Metrics
View
Tracking
Macro
Usage
Macros

32. Easy
Usability
Tes%ng:
Method
• Schedule
15
minutes
• Ask
them
to
answer
a
ques%on
• Observe
how
they
answer
(2
min.
max)
• Ask
5
more
ques%ons
• Repeat
with
5+
more
people

33. Easy
Usability
Tes%ng:
Ques%ons
• Did
they
search
or
browse?
• What
keywords?
• Where
did
they
start?
• How
many
levels
deep?
• Did
they
find
the
answer?
• If
not,
what
did
they
expect?

34. Easy
Usability
Tes%ng:
Results
• 55%
TOC,
45%
search
• Users
skip
landing
pages
• Users
only
check
top
2-­‐3
results

35. Ques%on
Tracking
V.1:
Simple
Journal
3
PMs
for
3
weeks
=
80
ques%ons
from
37
people

36. Ques%on
Tracking:
V.1
Results
Easy
45%
55%
Hard or
Missing
17%
50%
43%
40%
Same 8 people
50%
TPM
Everybody else
Other
42%
58%
EM
New hires
Veterans

37. Ques%on
Tracking
V.2:
JIRA
Agile
Rapid
Board

38. Knowledge
Mapping
Type
of
Product
Info.
Role
of
Employee

39. What
did
I
forget?

40. Your
Business
Case

42. Model
your
wiki
a9er
a
Na%onal
Park.
1.
Sustainable:
Easy
for
your
team
to
maintain.
2.
Accessible:
Easy
for
everyone
to
find.
3.
Credible:
Easy
for
everyone
to
believe.

43. The
BOOK
• Internal
Guides
• Client
Guides
• Product
Roadmap
• Opower
Glossary

44. Sustainability
1.
Only
what’s
cri%cal
• Use
templates
• Exclude
“extra”
info.
2.
Plan
for
maintenance
• Build
snippets
library
• Mul%-­‐excerpt
&
archive
macros
3.
Allow
contribu%ons
• Set
boundaries
• Ad
hoc
workflows
macro
Ad
hoc
Workflows
Macro

45. Accessibility
1.
Search
and
discovery
• Create
mul%ple
paths
• Target
content
by
role
2.
Lessons
from
UX
• Toc
<
3
levels
• No
content
only
on
landing
pages
3.
Other
systems
of
record
• Incorporate
data
• Keep
people
in
their
workflow
BOOK
TOC

46. Credibility
1.
Set
cri%cal
content
apart
• Keep
it
in
different
space
• Suggest
space
search
2.
Brand
it
• Add
a
logo
• Use
unique
colors
and
layout
3.
Promote
it
• Get
endorsements
• Go
on
a
roadshow

47. Results
“This
is
going
to
help
Opower
be
a
be?er
company.”
-­‐
Execu%ve
“The
BOOK
looks
great.
Using
it
daily
already!”
-­‐
Client
Engagement
“BOOK
=
RAD”
-­‐Technical
Staff

48. 30
Day
Metrics
Welcome
Page
10X
• Old
=
134
page
views
• New
=
1,469
page
views
Alerts
Guide
Page
7X
• Old
=
43
page
views
• New
=
294
page
views
4th
Most
Popular
Page

49. Solu%ons
Summary
• Use
knowledge
management
to
enable
hyper-­‐growth.
• Manage
your
wiki
like
a
product.
• Model
your
wiki
a9er
a
Na%onal
Park.

50. =
Page
views

51. OFun
on
the
Wiki

52. 1. What
if
I
don’t
have
enough
people
or
resources?
2. What
if
I
can’t
afford
plugins?
3. What
if
I
can’t
get
cross-­‐team
consensus
on
a
solu%on?
4. What
if
I
don’t
have
support
from
management?

54. Any
ques%ons?

55. Rate this Talk
Cultivating Content: Designing Wiki Solutions that Scale
Text code below to 22333
or visit http://bit.ly/197j4mC
MEH = 2Q
NOT BAD = 2R
PRETTY GOOD = 2S
AWESOME = 2T
To join this session, send text 136888 to 22333