Guest lecture on product and project management in legal design, held on the course Introduction to Legal Design at Stanford University’s d.school 2015-05-07.
Anna Ronkainen(this space intentionally left blank) at F:ma Naanebax, ex-TrademarkNow
Introduction to legal design: Product & project management
1. LAW-761 Introduction to
Legal Design
ProCVct Management and
Legal Design
Stanford Law School/d.school 2015-05-07
Anna Ronkainen @ronkaine
anna.ronkainen@trademarknow.com
2. Look who’s talking
Anna Ronkainen
- a lawyer at least on paper (LL.M., U of Copenhagen);
also studied EE/CS, linguistics; researcher in
computational legal theory (U of Helsinki)
- Chief Scientist and co-founder, TrademarkNow Inc.,
head of product 2012–2015
- just taught Intro to Legal Tech (U of Turku)
- worked in the software industry since the early 1990s,
in project and product management roles since ~2000
- serious design (especially typography) geek; occasional
usability scholar as well
3. Today’s topic: two different things
(that sound confusingly similar)
Product management: figuring out the what
Project management: figuring out the how
(who, where, when), and making sure it gets
done
Different tasks, different skillsets, but still
many things in common!
7. Any successful product manager’s most
important day-to-day tool:
“NO!”
(Still, it *can* also be overdone: http://vooza.com/videos/just-say-no/ )
8. Why you should end up saying “no” to
most things
- you can’t (and shouldn’t try to) do
everything, product focus is crucial
- (most) end-users are not designers: their
suggested “improvements” would usually
make the product worse
- still, they are indicative of real problems and
tell where you should dig deeper to find out
what the actual problems are and how to
best address them
11. 12 arguments you should say no to
1. But the data looks good
2. But it’ll only take a few
minutes
3. But this customer is
about to quit
4. But we can just make it
optional
5. But my cousin’s
neighbour said...
6. But we’ve nothing else
planned
7. But we’re supposed to
be allowed to work on
whatever we want
8. But 713,000 people
want it
9. But our competitors
already have it
10. But if we don’t build it,
someone else will
11. But the boss really wants
it
12. But this could be “the
one”
(from Intercom on Product Management)
12. Things to consider before saying yes to
product features
1. Does it fit your
product vision?
2. Will it still matter in 5
years?
3. Will everyone benefit
from it?
4. Will it improve,
complement or
innovate on the
existing workflow?
5. Does it grow the
business?
6. Will it generate new
meaningful
engagement?
7. If it succeeds, can we
support and afford it?
8. Can we design it so
that reward is greater
than effort?
9. Can we do it well?
10. Can we scope it well?
(from Intercom on Product Management)
13. Design thinking
- Peter Drucker: the job of designers is
“converting need into demand” – figuring
out what people want and giving it to them
(i.e., innovating)
- Tim Brown of IDEO: The challenge for
design thinkers is to “help people to
articulate the latent needs they may not
even know they have”
- desirable, viable, feasible
14. Design thinking tools
- insight: go out into the world and learn from
the lives of others
- observation: watch what people do (and do
not do) and listen to what they say (and do
not say)
- empathy: stand in the shoes of others,
connect with their emotions.
15. Concrete product design tools
- interviews
- questionnaires
- think-aloud
- personas
- user stories (“as a ____, I want to ____ in
order to ____”)
- doing it yourself
- product roadmap
- (A/B tests)
17. Apparently legal project management
is the next big thing
- legal industry finally catching up with every
other industry
- e.g. seeing litigation as a project with a
beginning, middle, and end, and considering
it as a whole, and not just until the next
deadline
- fair share of buzzwordism and other cargo
cults
22. Useful project management tools:
Scrum
- team roles: product owner (≈ technical
product manager), scrum master, team
- work organized into sprints (constant length,
typically 1 week – 1 month)
- events in standard scrum development
- sprint planning
- daily scrum/stand-up meeting
- sprint review (what did we do)
- sprint retrospective (what did we learn)
26. Be agile, don’t “do Agile®”
- in a larger project, have some sense of
overall direction, but don’t think you can
design everything at once
- plan for something a sprint, do it, get it out
to users, evaluate and plan next iteration
- focus on doing things mindfully, use your
common sense as well as your own domain
expertise rather than just think following
some methodology will solve everything