Cover-photo-2018-03-22_13_03_45__0000-1487820180322-4-1d7d7nx
CTodd Lombardo

CTodd Lombardo

Boston (Salem) / Madrid VP of Product & Experience @ Vempathy // Data Viz & Product Geek // Adjunct Prof @ MICA and IE Business Joined about 5 years ago

  • 9 stories
  • 50 comments
  • 8 upvotes
  • Posted to XD-Awesome: XD plugins from the community!, in reply to Mike Hu , Feb 14, 2019

    Well, here it is!!

    0 points
  • Posted to XD-Awesome: XD plugins from the community!, in reply to Mike Hu , Feb 08, 2019

    We're releasing it to the XD plugin store in next week!!

    0 points
  • Posted to Does anyone here actually use UI kits?, Feb 08, 2019

    Heck yes. Why reinvent the wheel? Though I rarely ever use them without customization or tweaking. Actually, I've never used one out-of-the-box. They save me and my team a ton of time as the components are mostly designed.

    The counter argument is you still need to edit/tweak and this could actually take more time then creating from scratch, but I believe we still save time in the long run.

    1 point
  • Posted to XD-Awesome: XD plugins from the community!, Jan 09, 2019

    Awesome indeed! Psyched to get our plugin out there :)

    3 points
  • Posted to How to Deal With A Creative Meltdown, Dec 31, 2018

    Ah, just go write a medium post at 10:30pm? Got it. Thx!! ;)

    0 points
  • Posted to Starting as a product manager, in reply to Matt Baxter , Dec 17, 2018

    Thx for the recommendation!! :)

    0 points
  • Posted to Starting as a product manager, Dec 17, 2018

    Sign up for Mind the Product's newsletter. Read Never Split the Difference to learn good negotiation skills. You'll need 'em. And once you're settled in pickup Roadmaps Relaunched. (I'm not biased on that or anything :D )

    6 points
  • Posted to Starting as a product manager, in reply to Scott Thomas , Dec 17, 2018

    The ability to prioritize is the number one skill of a product manager.

    3 points
  • Posted to Are design sprints sustainable at your company? , Sep 29, 2018

    Hey —

    I co-authored the first Design Sprint book ( the "other less-popular" one ).

    I was at a B2B SaaS company (Constant Contact, now part of Endurance) when I wrote it, we started it because in late 2012 there was maybe one or two blog posts from Jake and the GV team about sprints. We were doing them inside a larger organization and most of the posts at the time were about design sprint in startups so we started codifying our knowledge initially to train teams internally, and that ultimately lead to converting it into a book, cookbook how-to style. (more on that journey some other time).

    I've personally led over 120 design sprints, mostly in large organizations and for a variety of topics, not just design or product, but service, technology, finance, HR, etc. We experimented with a zillion flavors of them: 1-day (too shallow), 3-day (maybe?), spread out over multiple weeks (don't bother), half-sprint (for ideation), etc in order to account for the enterprise culture of "I have no time" or "that's too much of my day." Some worked. Some didn't.

    A few things I've learned: 1) There's no magic bullet. So many people look to mechanisms like this to solve much larger problems that may be around org structure, incentives, team makeup, product/technology performance, etc.

    2) Timing: My colleague Jill Starret suggested a 10a-4p session, which worked wonders for many teams as it did take enough of the day to ensure focus, yet it allowed for individuals to still do their "day job" before and afterwards

    3) Plan, plan, plan beforehand but improvise during. Get information up front and if you don't have enough research that first day will be a mess. Do a "research sprint" ahead if you need to.

    4) Have a strong facilitator who is not a participant. Being a "Player-coach" is incredibly hard unless you have years of meeting facilitation experience.

    5) A full design sprint is rarely followed by another full design sprint, usually iterations of adjusting the prototype according to what you learned from the test, updating any assumptions you have and then testing again for what you need to learn.

    6) It's not about the outPUT of the sprint, rather it's about what you learned along the way.

    YMMV.

    Good luck!!

    11 points
Load more comments