Labor market: *realizing that their labor is underpaid*
VCs: Forget about that nonsense and do work for free instead, your boss will definitely appreciate it honest
You know what happens when you work weekends?
Everyone knows that you're the sap who will work weekends. That's it. You don't get ahead by doing more of the same work. You get ahead by making your impacts more visible, and good luck doing that when everyone's living their lives.
Instead of spending more time working, spend more time looking at why you need to work those extra hours, and attack the root cause. You'll cut the chaff and spend 40 hours a week on high-impact work, instead of 56 hours on nonsense other people have saddled you with.
Committing to work weekends to make a lousy manager's overloaded feature roadmap a reality will just get you an even more bloated roadmap next time. What exactly do you think you're getting out of it?
Getting taken advantage of because you refuse to set boundaries isn't a career life hack.
You want to use your weekend to build your career? Work on a side project, learn a skill, network, write some blog posts, become a person with an opinion. Invest in your own voice and value, not the bottom line of your employer.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The fidelity of your design artifacts needs to match the fidelity of your research insights. Getting ahead of your knowledge with beautiful mockups that rest entirely upon assumptions is AT BEST wasted work, and at worst burns design's credibility with stakeholders.
1/🧵
Without research, the value of anything you're drawing is purely speculative. But it doesn't look like it to non-designers - without being immersed in the use case, all they see is "the design is done." They will expect to see that thing built.
2/🧵
When new evidence suggests that this design is not the right solution, it will be a struggle to convince stakeholders that changes need to be made. Even if product hasn't already started cutting tickets and scheduling work - the first design sticks firmly in people's minds.
3/🧵
"Don't worry about edge cases or errors, this is an MVP" is a very dangerous line of thought that I usually hear from people used to designing for stakeholder demos, rather than production releases.
A demo for a stakeholder, especially a "user proxy", is a very different path from normal use. Any scenario has to contrive a path through every single one of the stakeholder's pet features, so usually it's a checklist approach instead. "We added XYZ like you asked, see?"
In reality, the "as a user I want to use X feature" user story doesn't cut the mustard - and without designing for plausible scenarios, the product ends up being entirely unusable.
If you're not designing for recovery from exceptions, you're not designing a viable product.
The business: hey we need you to draw some wireframes for this engagement
Me: Do we have a scope for the problem? How are the user's existing tools failing them? Are we resourced to answer these questions?
The business: nah it's ok they can be low fidelity wireframes
Design artifacts are not the deliverable. They just document the design decisions, and design decisions must be rooted in user research.
If you can't draw a direct line from the artifact to how the decisions it documents will be informed, you won't produce anything of value.
Before someone sets pencil to paper, it's really easy to think you have something while remaining pleasantly vague. Only when you need to render the artifact do you realize that there's no there there. It's up to the designer to say "hang on, I can't do anything with this."
Product ownership is an interesting challenge - you want to limit WIP and avoid context switching, but you can't just laser focus on building and neglect caretaking.
This is why trying to develop many new things in parallel doesn't work, and why single threaded leadership is so effective. Without consciously attending to all the dimensions of the product, you'll build an unstable tower that is constantly collapsing.
This model also shows why focusing on outcomes is more important than outputs. The second approach looks tempting from a feature factory perspective, but if you have visibility into outcomes, the work in the first approach becomes just as meaningful.