We’re integrating a service that will send our transactional emails. There was a cursory eval from tech leadership when shaping the pitch. Now that we’re in cycle, we see things that couldn’t have been known without starting the work.
Integrating 3rd party tech seems ripe for rabbit holes that can’t be truly anticipated until you’re in cycle. A special class of discovered work.
How do people handle betting on pitches that depend on 3rd party services and their unknowns?
We have a very often similar issue. The last time we build a proof-of-concept using the 3rd party API before the cycle to validate that the API is usable and there are no huge issues. Once we validate that, we prepare the pitch and start the cycle where we did the full integration.
Oh cool - makes sense to help derisk. How did you like that approach? Were you happy with the result? Is the individual or proof-of-concept team on other projects at the same time? Or is it considered a small batch chunk of work?
Yeah, I think it works well. Of course, it also depends on which state the API is in. E.g. it’s different if you’re integrating with API that is working for years and it’s stable vs API that is also in development. For us, it was the second case. And this proof-of-concept really helps, because we could give the other vendor early feedback about what they should improve. Still, there was plenty of discussion with them during the development itself. But yeah, it helped. We would definitely do it again.
For me, this proof-of-concepting is actually part of the shaping phase. Basically, it’s technical shaping and you need to dedicate time for it. We start this in cool-down, but we didn’t finish, so we simply say “okay, this is important, let’s postpone the next cycle for a week, and let’s really finish the proof-of-concept to make sure there will be no surprises.” So, yes it was a little bit unorthodox because we had 2 weeks of cool-down, then 1 week of “technical shaping” and then 6 weeks of the cycle.