I don’t like either of these options. Of course, the employee in me wants to be rewarded for producing efficiently, and the manager in me wants to take advantage of that efficiency to improve the business overall; this is the simple conflict that the question hinges on. But Daniel’s question and its two options miss the mark entirely because they assume that the employee is being paid either for their time, i.e. selling hours, or by the task or piece, i.e. selling some number of completions of a well-defined task.
This is not how I want to arrange my work or the work of the people I support. I am not paying them for their time, and I am not paying them by the piece. And I can’t really; as knowledge workers
our work is not so well-defined as to be sensibly thought of as piecework, and
our time is not a good unto itself, rather it is the way we apply that time that produces results that are valuable.
Knowledge workers negotiate and accept anticipated results they are to participate in producing, and then act largely as they see fit to do so. They are paid a salary and evaluated based on their contribution to these results. It’s hard to do a good job without some amount of continuous improvement, as we are learning as we go, and a valued contributor will find ways to do a little better than last time.
That improvement has a few rewards:
it produces a sense of accomplishment,
it creates success for the team and organization, and
it makes the job easier over time,
it frees up some effort to work on more interesting things,
it makes space for the employee to make decisions about balancing their ambition and their need for rest.
In the ideal case, all five of these rewards are produced.
There are a few ways these meetings might be organized depending on where we are in the design-development process.
early concept: help me think about the problem
late concept: help me choose among these ideas and develop one
early detail: this is where we are going, what caveats remain?
late detail: here’s a the detail, what questions do I need to address?
These depend on the thought that there are a few phases/horizons to product design work, namely
Problem Framing (aka Research or Horizon 3), in which we learn about the challenges and needs of users to understand and select a problem to go after with concepts,
Concept (or Horizon 2), in which we develop concepts and select among them with the help of users and engineering, and
Detail (or Horizon 1), in which we develop the selected concept and test the fitness of our more detailed work with users as we go.
It’s a common anti-pattern that engineering gets involved only when we are in detail, but we’d like to pull them into the other phases to be informed about the available problems and to help us develop and select among concepts.
Some Agile purists will decry this phasing as anti-agile, but that requires a blinkered view of what Agile means, which often comes about when one confuses Scrum for Agile. (The dirty little secret of Scrum is that there’s a lot of hand-waving about the large quantity of work that needs to happen outside of sprints to make Scrum possible.)
I tend not to be in favor of output metrics like these; they’ve been shown to be counterproductive for developers (lines of code, commits, bugs crushed, etc.), for example. But I am thinking about how best to apply the process maturity scorecard to the work of the individual designers to try to coach them on their projects. If a designer is helping to improve the process maturity of their product team(s), that’s a good sign.
On the other hand, some anti-metrics (trouble indicators) are pretty obvious – if there’s a lot of rework coming back to a designer, if deliverables are sloppy, if product managers and engineers are dissatisfied or under-involved, then we can tell there is a problem. But the opposite of these are not great metrics for individual performance, as a certain amount of rework will be technically driven, we don’t want to create an inspection-heavy situation where each deliverable is scrutinized for lack of sloppiness, etc.
I do have expectations that designers will bring work to and contribute to critique, seek my counsel on design challenges, press for collaboration, etc. But do I want to count these behaviors? Probably not. The ideal thing would be to peg team performance to the product metrics we hope to install. The metrics we really care about are user success metrics in a product, and these are team metrics, not individual performance metrics.
So when it comes time to evaluate a designer, I like to use four Cs – customer, collaboration, culture, and content.
Customer – is the work produced by the designer informed by the customer, appropriate to the customer, accepted by the customer?
Informed a leading indicator, evidenced by their participation in research and testing. They are or are not doing this. Exactly how much is situational, nonnumeric.
Appropriate is somewhat evident in testing, and ultimately evident in adoption, a lagging indicator (and highly dependent on product and engineering decisions, the appropriateness of the feature idea in the first place, etc.).
Accepted is essentially adoption. The same caveats apply.
Collaboration – is the designer an effective collaborator on their project teams? Do they work well with their peers and their project teams?
Culture – what is the designer’s contribution to the culture? Are they intellectually and emotionally engaged in a way that improves their teams and the org, is neutral, or detracts from their teams and the org? Are they improving and helping the culture improve?
Content – is the designer’s work organized, communicative, complete, insightful, timely? Are their skills and attention to detail usefully on display in their work?
At work there’s been a move afoot to tag items in our roadmapping tool as “globalization,” “internationalization,” “localization,” or “translation.”
The executive level thinking here is that we are not offering our products globally, and need to be. So what do you do about that? You globalize!
To my thinking, though, there are universal requirements, things that the underlying product should do everywhere, and requirements borne of local data formats, terms of art, regulatory environments, etc. Universal versus local. Then there’s the work of offering interfaces and commendation in a newly-supported language, and the things you must do technologically to make your application able to deliver these universal and local requirements and serve interfaces and documentation in the correct languages.
To my thinking, a universal requirement is just a requirement. The special ones, therefore interesting to tag, are
localization: things that need to be done differently due to a locale’s needs – preferred data formats, regulatory environment, terms of art, etc.
translation: the actual translation of interfaces and documentation into a newly-supported language or English variant
internationalization: things that must be done technologically to enable us to address either of the above
A tag that would be applied to all or almost all of the items seems like it might not be that useful. Globalization is the goal, not a specific type of work. It probably doesn’t make sense to separately call out universal requirements, as these should be numerous. Most work should be universal.
Meanwhile, globalization also includes marketing and sales and support and other things. Trying these terms on wrt marketing: we want to globalize our marketing, so we consider the universal messages we want prospective customers to understand (which should not be a special effort), then we look at how these might need to be localized (made locally specific/applicable) and translated (in the right language), and what processes we need to internationalize (tech/process/people to enable the above) to make conveying these messages possible.
I might be thinking about this wrongly, but this is my current understanding.
Heather asked me yesterday “who owns accessibility?” That’s a fun question. I replied:
Accessibility is not owned. Who owns quality? It’s a team responsibility. To the extent that accessibility compliance, or release date, or the P&L is a “feature” of a piece of software it is owned by the PM, but each function has its responsibilities in accomplishing accessibility. Making these responsibilities explicit is necessary.
The folks with responsibilities mainly include UX (designing for accessibility), FED (engineering for accessibility), QA (inspection), and PM/PO (prioritization). These aren’t collected in one person’s purview around here until the CEO, so that’s not the answer to your question.
If we are to be product-led and not sales-led, PM has to insist on it (and manage competing priorities), maybe that’s part of the answer.
The “ownership” urge seems to sometimes dilute or deprioritize the responsibilities of others, which is a shame because we must work in concert.
As of nine weeks ago I have a new job at Cayuse. But how do I explain my accomplishments on LinkedIn when I’m so new?
Maybe I don’t. What if I instead explain what I am there to do? What would that be like?
I am building a design and research team to support the collection of 25+ disparate built and acquired products into a single coherent suite. Since I’ve recently begun, here’s what I plan to accomplish: • Develop UX and UI design capacity and capability • Add and develop UX research capability • Install formative usability testing during design to de-risk detailed design decisions • Install user insights research, concept design and validation • Stand up a team and processes to build and improve a design system in visuals and code, for the product suite • Gather and improve product personas to be an informative smaller set of personas for the entire suite • Begin instrumentation of new features, to measure outcomes, by determining desired outcomes at the epic level • Help the product team take advantage of existing pre-customer and post-launch data, such as customer success contact data, support forum and knowledge base behavior, RFP mining, sales demo feedback, etc.
My impression is: 1) When we pressure people to overproduce we encourage them to defend themselves in ways that seem locally sensible but turn out to be anti-collaborative. 2) Financial planning, especially when the business is not self-funded, tends to require a forecast; that forecast hangs from a roadmap, effort estimates, and sales targets. 3) When a business sees the sales team as its economic engine rather than the product itself (sales teams tend to be good at preserving this impression), opportunities detected by sales get pushed onto that roadmap with less discussion than necessary.
I find I often have to nudge people out of what I’ve come to call constraint-based thinking. Focusing on and reacting to the apparent constraints in a situation can lead to a poor solution and a feeling of being stuck with that poor solution, a double-whammy of negativity. “We couldn’t do X because of A, we couldn’t do Y because of B, so we’re stuck with Z, like it or not.” Chances are good that there’s a way to meet the goal that manages or makes irrelevant these constraints that you’ll be happier with than where you are seemingly stuck, but it requires exploring ways to meet the goal rather than rattling around in a box of obstacles.
Steven Forth responded:
Are there skills we can cultivate that helps us escape from the self-imposed constraints of constraint based thinking?
So I elaborated a bit:
Sure. Some are implied above.
1) Identify and articulate a goal as a benefit (where a benefit is the happy result NOT expressed in terms of exactly how it is delivered).
2) Consider a person’s needs and a business’s needs together rather than separately.
3) When confronted with a problem or pain point, learn about and offer possible benefits (some folks call them “gain points”) rather than solutions, at first. Later you can design or select a way to deliver that benefit.
4) Think in scenarios: who arrives in what situation, when and where, with which need or goal to address or accomplish, and what can the system (or organization, etc.) offer them?
Note that most of these thoughts require a positive wording of the situation or aim rather than a negative wording. This might be the key skill, broadly useful but not sufficient on its own. You’ll see this in health fields when practitioners take a wellness perspective—rather than cease some harmful behavior like smoking, they’ll talk about replacing the habits associated with smoking with healthier rituals, moving nicotine delivery to a less-harmful medium where it can be managed, etc.
Gentle people, I recently complained to the directors and project managers about meeting invitations
without agendas, or
without a clear goal, or
without a sense of what a person might be expected to do in a meeting, or
without a sense of what person might need to do to prepare for a meeting.
It turns out that, generally, the project managers aren’t to blame here. The VPs and directors are to blame more than we should be, but especially the populace—most folks are not that great about helping the folks they invite to a meeting be ready for that meeting.
This is a thing that design folks can be especially good at. We’re accustomed to thinking about others and their needs. All we need to do is remember to think about these at the moment we are scheduling the meeting.
The people who are coming to your meeting need to know what the meeting is meant to accomplish and how they are going to be useful. Please tell them by including that information in the invitation.
There are lots of great articles about developing a roadmap for a product or service. But sometimes these processes can seem too heavy, too slow, or too strategic (is there such a thing?) for the task at hand. A lightweight process, aimed at selecting and ordering improvements rather than expressing an ideal and working toward it, can work when certain conditions are met.
The product (or process or service) exists already.
Stakeholders are certain the product does essentially what it is supposed to do, but are dissatisfied by the results.
There are too many potential problems and potential fixes to clean them all up in a single project, though this is desired, or
the political situation is such among stakeholders that choosing a good place to start will be difficult (some may not want their area touched, others may want to go first, still others may not want to work.
These conditions assume that the strategy is good, and that the stakeholders’ attempts to fulfill that strategy are based on sound choices, but are perhaps not well-executed.
To successfully produce a roadmap and manage the political situation among the stakeholders we must accomplish a few things:
Uncover and arrange opportunities for improving the product.
Group and sequence the opportunities.
Plan the work for the first step on the roadmap.
Along the way we must be careful to:
Make good use of any work the stakeholders have done to date.
Demonstrate to stakeholders that we understand the current situation.
involve the stakeholders in determining the value and feasibility of addressing each opportunity.
Involve the stakeholders in negotiating the roadmap and selecting the first step.
Stakeholders appear in each of the four points above. We must bring them though this process and ensure that they are heard, and are at times active participants, but we must not become wrapped up in their shenanigans. There are defined points in the process where we involve them.
The first few steps of the investigation phase will occur together, and as you learn more you may find yourself returning to stakeholders for clarification, more information, or scope adjustment. The investigation phase typically takes the longest of the three.
Stakeholder research to establish goals and wishes, and collect their ideas.
Primary user and stakeholder research to understand existing needs and processes and learn of opportunities
Review secondary research (research done by others).
Express any found problems/opportunities (often pain points) in terms of their benefits (“gain points”) and likely features.
Arrange these opportunities by theme to see if and where problems are concentrated.
Step four is critical: you’ll have detected many problems and pain points, but need to express them first in terms of a benefit you’d like to deliver rather that just a feature. Remember that a benefit is the result of having a problem solved expressed without regard to the exact method of solving it. If you learn that students struggle to fill out a financial aid form on time, it would be tempting to offer an advisor to help them. That’s a feature, and it might not be the right one; the benefit may be that students have the information they need to fill out the form quickly and submit it easily. Go ahead and offer features, but only after identifying the benefits. The stakeholders will help us choose features once the benefits are clear.
We arrange opportunities by theme now to see if it tempts the stakeholders to narrow the scope of the project. You have to start somewhere, and the earlier we can reduce scope the higher the likelihood that the project will produce a useful first increment.
At this point you’ll have be ready to show the stakeholders your understanding of the current situation and the opportunities you’ve uncovered. This will fulfill both “make good use of any work the stakeholders have done to date” and “demonstrate to stakeholders that we understand the current situation” reminders above.
You’ve produced the raw material necessary for the stakeholders to help arrange opportunities into a rough sequence. Depending on scope the entire synthesis phase could be done in one workshop, or it might require two with some thinking and preparation in between.
Have a workshop with stakeholders to score opportunities by value and feasibility.
Examine the high-value, high-feasibility opportunities for common themes, then sequence all opportunities within these themes according to value and feasibility. More doable and higher-value items come first, and valuable low-feasibility items come last.
Have a workshop with stakeholders to arrange these themes in sequence according to feasibility and value.
Scoring opportunities for value and feasibility is a simple matter of placing these on everyone’s favorite business diagram, the 2×2 matrix. Items in the high-value, high-feasibility quadrant are potential good places to start. You’ll want a small but politically-effective number of stakeholders in this meeting; too many and it will be hard for the group to make decisions. too few and they won’t be informed enough to make good decisions.
This process requires you and the stakeholders to discuss how each of the opportunities might be met; what improvement (feature or change) would deliver the desired benefit. So we are sneakily involving the knowledgeable stakeholders in choosing improvements to deliver the benefits. They will feel useful pressure to help come up with high-feasibility ways to address high-value items.
Some items will be high-feasibility but low-value. These are nice-to haves that probably should not appear in the ultimate roadmap. Put them in a parking lot so that no one need be sad about them being cut outright. Still others are both low-feasibility and low-value. The stakeholders might have pet items among these. They should also go to the parking lot unless great ideas come up about how to rethink them, their value and feasibility jumps as a result, and the prior research supports their inclusion.
The themes that emerge from looking at the high-value, high-feasibility items are more informative than the rough themes we offered in the investigation phase, and will govern the arrangement of opportunities in the roadmap. And when you look at them you will likely see that some of these themes contain more high scoring items than others.
Offer these themes and the improvements they contain to the stakeholders in a workshop, and ask them to put these themes in order. If we could work on just one theme, which theme would we choose? That one will be first. By the end of the workshop you’ll have themes in a rough sequence, and within these their opportunities in a rough sequence.
You could stop here, but it is likely that the stakeholders aren’t done yet.
Now that you have a sequence of themes, and within those a sequence of improvements, you have a roadmap. But it puts some lower-feasibility items ahead of others just because of the themes they appear in. It also may offer a sequence that is awkward to accomplish, or doesn’t begin addressing top organizational goals early enough. Time for negotiation.
In a workshop with stakeholders, negotiate tradeoffs in improvement sequencing to better meet organizational goals.
Once that negotiation is complete, in that same workshop select one or a few items earliest in the sequence to make up the initial project.
Then go away and plan and estimate the cost in time and treasure to effect that project.
If you have the right small group of stakeholders, they’ll notice that they can rearrange some items to have the roadmap better address systems, efficiency, or political factors, start delivering against key goals sooner, or have certain improvements essentially make decisions early that will be helpful when tackling later improvements. Let them make these tradeoffs. The integrity of the themes is not important; we used the themes as a tool to make the rough sequence easier to accomplish.
After the tradeoffs are done, look to the items at the early end of the roadmap for the scope of the first project. It is tempting to bite off too much; everyone is excited about all the things you’re planning to do together. It’s best to keep the scope of the first increment small, achievable, not too expensive. Short projects with narrow scopes are more likely to succeed, after all.
Why not define an ideal?
You’ll note that this process does not define an ideal end state nor attempt to arrange a roadmap to produce that end state. End-state-based design is interesting (and there’s a very nice process called Ideality that depends on an understanding of the ideal), but I’ve elected not to make use of it here. There are several reasons for this.
Producing an expression of an ideal end state, when there are lots of potential improvements, is expensive.
The sequence of roadmap items aimed at an end state is likely to be different than a value- and feasibility-weighted roadmap which leads to high value improvements more quickly.
Understanding and acceptance of an ideal end state tends to decay rapidly as business conditions change and new information and technology becomes available.
Commitment to an end state reduces optionality, the ability of the organization to make new decisions about the future as needed.
Instead, this roadmapping process relies on the improvements themselves and especially benefits they are intended to deliver to take the place of an ideal end-state. These benefits express the desirable future in a diffuse, less-specific manner. Indeed, the later and less-feasible an item on the roadmap the less likely it is to be developed. this is true fo end-state-based roadmapping as well; the likelihood that the organization will pursue the entire roadmap diminishes over time. Why not embrace this constraint?