Subscribe
Share
Share
Embed
A podcast from the ETEN Innovation Lab exploring acceleration in Bible translation. Tune in for experimentation, updates, and conversations about new methods and technologies advancing Scripture accessibility.
Isabella Scarinzi 0:04
So welcome back to the Bible Translation Innovation Podcast, a show brought to you by the E 10 Innovation Lab. Today we are joined by Joel and Clappy, as usual, but for this episode, since we're talking about product management in Bible translation. We also have a special guest, Chad Wide with Glue. He's working on the development team for the Fluent app, which we've mentioned many times on this show before. So, welcome, Chad. Would you mind telling us a little bit about your background and what kind of work you do in Bible translation innovation?
Chad White 0:41
Yeah, thank you for having me. It's, it's good to be on one of these, as I listen to them many times over and enjoy listening to them. So, I've spent in the past 24 years with SIL, about half of that time I spent working as a researcher in language survey. The last 12 years I spent as a developer and project manager for the Ethan log. I worked on the front end and back end systems that we built, and the main website, the wikis, a lot of typesetting of the ethanol log books as well, so a lot of technical stuff there. The last two years of that time I spent more and more of it doing product management types of things, helping to design the systems that were being built at the time. Then a little over two and a half years ago, I shifted to full-time product management. First, I worked on the aquifer, and then, since, as you mentioned, since last summer, I've been the product manager for Fluent. So that's, yeah, that's a little bit of background on on me. A
Isabella Scarinzi 1:43
lot of experience in Bible translation, it seems. That's awesome. So, before we go any further into this episode, I'm hoping we can get a solid definition. So, what would you say is product management, and what does that look like in Bible translation?
Chad White 2:01
Sure. yeah, product management is really all about the user, so in Bible translation that means understanding what translation teams need to do their work well, then also making disciplined decisions about what to build for who and what order. There's a lot of decisions in that, in that sense, that come in in product management, increasingly, especially in the last, how many years, few years, and more. These teams are minority language speakers, translating scripture for themselves and for their own communities, which means that the user inputs are that puts the user close to the mission itself. It's not just some user who's going to be using the software, it's actually the one who's going to be using the end product that comes out of the software. And so the unique challenge is that you're always accountable to two things: one, does the tool serve the translator, but does it also set them up to produce something that's going to serve the people that they're doing the translation for, so those are those are kind of important. If you, you can build a tool with great user experience, but it fails if it produces a workflow that leads to say an imprecise translation, and so you're always holding those two things up. Does it serve the translator, and is the translator being able to do the work that's going to serve their community well. I would say beyond that, the organizational ecosystem is uniquely complex. You've got SIL, Wycliffe, Biblica, PBT, LBT, you know, all these different translation organizations, and the relationships within the communities that they work in, those are strong. They also have opinions about the methodology that's going to be used, and so there's a lot of product management in this space, is making decisions that can be trusted across the whole ecosystem, and not, or at least across a portion of the ecosystem, not just within one organization, because, of course, trying to serve everyone equally is often how you end up serving no one well, so the goal then becomes to build something that's so good for the translator that the organizations trust that the translators pick it up and begin to use it. So I'll stop there. Product management is all about the user, that's the bottom line.
Klappy 4:16
That's great, Chad. Working with Joel for years, you know, especially me, coming from the technology side, I've spent so much time and effort trying to figure out what's possible, what's on the horizon, and and building proof of concepts, and through the years I've watched Joel go more and more like focusing on, okay, well, what, what, what is the use, what does the user need, you know, what is the actual use case? How do the users approach the tool, and I've seen Joel's journey refining and focusing more and more on the user, and I feel like what we ended up winding up over the past 10 years is ending up to a point where we. We needed a product manager, you know, like you and Joel. I've seen your essays through the years and seen them get closer and closer to defining the need, but not out of, like, textbook, you know, reading, but actually out of real felt need of creating products for Bible translation. So, maybe Joel, if you don't mind sharing a little bit about your journey in that.
Joel Matthews 5:23
Yeah, thanks, Clappy, that's a kind way of saying that you run from mistakes. I have started off, my bent is definitely more towards the code and building software, and I'm excited about new technology, and as somebody who sees and eat on the field with my bent, you, your first instinct is to start building something as you, as the first time you see the need, and I'm very guilty of doing that multiple times, and what I've learned is that may not be actually be helpful for the user you're trying to help, what they might say is, hey, this, this is really cool, but there are all of these other things that probably you didn't take into account, and that really doesn't, this doesn't meet the need, and so over the years I have kind of become a lot more conservative in starting to code and in wanting to take some time to understand what are we building and why we're building it, and this is really Chad's bread and butter and product manager, as a product manager for Fluent, he's he's really helping us think through these questions effectively, even as we think through every feature and every decision of every button and flow, and at the same time, we don't want to make it so onerous that we can't get anything done, and the development team is held up, so there is a balance, but it, there is some intentional, deliberate thinking for every feature that we are putting in before we do coding, and my, my learning over the years is this produces a lot more fruit, so you, you know, you can do coding for different reasons, you can build the tools for different reasons, and sometimes it's self-satisfaction. It's really fun to build stuff, and it's really cool to see it just out there. But if, and there's nothing wrong in that, it's good to do that. But if you are trying to actually affect change in somebody else's workflow and help them do their work better, it behooves you to kind of slow down, work with them, know them better, know their work better, and then attempt to build solutions with them while they're in the loop, so you don't, you don't go off and to a corner, build a big monolith, and then come back to them after a year and say, here, this should solve all your problems, and only to realize their problems changed, their world has changed, and you're still a year behind. So, all of those are good lessons to keep in mind for somebody starting off with building a tool.
Chad White 8:18
I would say the worst case scenario in that, is that you misunderstood what the problem was that they needed solved in the first place, and if you don't stay close to the user and give them a little bit to play with, and then ask questions, you'll end up not, you'll solve the wrong problem, and that's that's also a pretty bad, bad place to be.
Klappy 8:38
Yeah, in there's a balance, though, right? Like, you can do both, right? It's not either or. You can still experiment and do the crazy things. I mean, working with you guys, you see the things that I do, but I think the answer is making sure you do both and you test things quickly, actually get in the hands of users, and you know, like you said, Joel, you can't build in isolation, and you also, you know, nothing will change if you don't push the boundaries, like, you know, there is a little bit of a pendulum swing back and forth, but we just have to make sure that feedback loop is tight.
Joel Matthews 9:17
Yeah, I really appreciate it, Clappy, all your pushing in attempting to try new technology and workflows, it's not the most comfortable thing to do, but it's really valuable, because sometimes they give, they pay off very well, so it's worth attempting to try new things.
Isabella Scarinzi 9:38
So now that we have a working definition, we know that many folks across E 10 are working to accelerate Bible translation. This podcast is about Bible translation innovation. So, when it comes to product management, what role does it play in accelerating pace, especially when we're developing tools?
Chad White 10:00
Yeah, sure. If you think back about how the way translation was done, and what were the bottlenecks, you know, things were constrained by access to language communities, or we still have it today, even consultant check, you know, they're waiting on, you know, consultants to be able to check translation that's been done. Funding, of course, is always always a problem, but the tools were almost an afterthought. Translators were working in Word documents and managing versions manually, and trying to sync things, and it was very slow, and very laborious, and very error-prone. And so, what product management brings to tool development is the discipline of asking the question of what is actually slowing people down, or where are the errors being introduced into the process, and then solving that, not just building, oh, we could do this cool thing, let's build that, no, actually asking those questions, what actually is the problem that we need to solve, so a lot of, you know, thinking back, a lot of that early translation software was maybe built by people who understood linguistics and theology very deeply, but they hadn't spent time watching a translator work, and didn't, didn't have maybe translate or software development principles, product management principles in mind as they built the software that they built. I'm thinking, you know, far, far back, but the result was tools that were technically capable, but practically cumbersome. I cut my teeth on some old DOS programs, or at least that's what they looked like, you know. And we wouldn't dream of using anything like that today. And so, when you apply a product management approach of user research, doing the prioritization that I mentioned earlier, iteration based on feedback from the field, you find those places, where does the translator lose an hour? Where does the draft get stuck waiting for review that could have been asynchronous? Where is a consultant traveling somewhere they didn't need to go because the tool didn't support remote checking, you know, this things like that, so you know, hopefully a translation project that used to take, you know, 25 years, maybe only 15 years, but it cuts down to 10, and that's that's years saved for a language committee that's no longer waiting for God's word in their language, good tooling informed by real user understanding is a meaningful part of that compression of time that I'm talking about, so I think the field is still early in adopting product management principles. The tools are getting better, there's a lot of room to go. It's an, it's an exciting thing to say, though, that that it is - we're beginning to understand, you know, what's possible as you apply product management, and I think about that in terms of it's been - it's been a few years, I think that product management has been increasing, but there's still a lot room to improve, so
Joel Matthews 12:55
yeah, what I like about product management that has a big impact on accelerating Bible translation, like Chad, you were saying, is it? It brings it back to our goals, like, what are we building this tool for in the first place? And sometimes the solutions are not technical. I think that's a, you know, it's obvious when you say it, but it's not obvious when you, when you're building tools, it's in your mind. Oh, you have to find the solution to this really hard problem, and it requires many years of research and development, and maybe there are, there are things like that, that it's worth the investment, but if you, if you don't take the product management aspect of it into account, you can get lost in your technical world and try to think that's the only way out, whereas what product management brings is, hey, have you talked to the user, have you talked to, have you taken time to observe the process, and you realize, yeah, it is a hard problem, but you know what? If you just ask these two people to talk when they, when they get to this point and actually make a decision together, we don't need to build this huge research-oriented feature that would take you years, and we can move forward. So it's really a practical way to move things ahead, seeing the field reality, taking into account the field realities, and I really appreciate that outlook, because the goals for any of our tools that we're building towards meeting the all access goals is not not to prove our technical grid, it's to get to actually need the old access codes.
Klappy 14:43
Yeah, and speaking of field realities, sometimes no tech or extremely low tech is what's needed in that doesn't come from building cooler tech, right? And no amount of AI can give the proper discernment to. We need to bring to meeting the users' needs, and you know, working with the lab's QA team, working on this review tool. We ended up creating a paper version, like a printout version of their tool, that way we could have a zero tech, not as a plan B or plan C, but as plan A, right part of plan A was actually bringing paper along with the tool to ensure there was compatibility for those who just were intimidated by using technology, and that actually you could hear the reports coming back from the first field testing of that is seeing people's relief when they saw that they didn't have to use technology they weren't familiar with, they could just use pen and paper that they were comfortable with, and I think that's that's exactly what you're talking about.
Isabella Scarinzi 15:52
So, Chad, is there a time when you were developing a tool or involved a project where you maybe you went out to the field, you talk to the users, and based on those conversations, that redirected or shaped the outcomes.
Chad White 16:09
I think an easy one to talk about is the aquifer, which we, I guess, it's been about two and a half years since I started working on that, and I haven't done any work hardly on it in the last nine months, but I was, as I mentioned, I was a product manager on that team, and one of the premises that we, we started with, and we really wanted to test was if we give the translator a draft zero, would it speed up the translation? So we had, we had a good team of dedicated translation managers with their teams under them, a lot of translators, and we had a handful of languages that we could work in as well, half a dozen, and so we could, we could test this, and so the engineering team, in particular, after conversations that we would have with the managers, and then the engineering team would talk to them, did round after round of changes to the way that the draft zero was produced, and the way that that it was presented in the software, and we found that it did work well in some languages, it didn't work as well in some other ones, but in the end translation was sped up by as much as 50% in some of those languages, so when the translator started with the draft zero, all they had to do was just be an editor, basically, and it did definitely speed that up, so they could just pass it on through to the editing and checking process. We didn't skip that, per se. We even had one language that it sped it up by as much as 90% which was pretty amazing. Of course, it was a large language, as you would expect, and there's a lot of data in the AI for that, but it was pretty, pretty remarkable.
Isabella Scarinzi 17:46
You mentioned large languages, a lot of the projects that we are working on are on in low resource context or oral context as well. So, how does that shape the way you approach your product decisions.
Chad White 18:03
Yeah, it definitely is a pretty large factor in as we think about developing software. In most software development, low bandwidth and limited devices are things you handle after the core product works. They're kind of bolt-ons or add-ons to the software, but in this space, where we're trying to actually develop software that is meant to be used in these environments, that the environment, the product has to be designed for those things from the very beginning. So, offline first, that's not a feature, it's an architectural commitment. When a translator loses their work mid session because connectivity dropped, there's not a bug report, that's a trust breaking failure. It's huge for the translator. They don't, you know, they don't want to lose work, so that's that's a very important aspect. And when you think about oral context, which you know, it kind of goes even deeper because they challenge your assumptions about what a product is. Clappy talked a little bit about using pen and paper. If the community doesn't read the minority language or doesn't read at all, then a text-based translation workflow may be producing something that the community can't actually receive or use, so that pushes you, of course, toward audio, toward checking processes that involve listening rather than reading. How you use AI to help with that checking, that's a whole nother challenge, but the product does change shape entirely in those situations. So, yeah, it's definitely a major factor.
Klappy 19:39
So, Chad, you just described like so many different problems from different situations and different scenarios and different languages and regions, and the complexities are even more than than what you've covered so far. So, how do you manage that? In how does that impact like your tool? Choices, or how you guide the software development,
Chad White 20:05
so the complexity of the breadth you mean of of the the situation with all these different types of communities and things, is that what you're asking?
Klappy 20:14
Yeah, I mean it seems like grossly overwhelming, like I mean I've been there with you, right, like you know, when you look at all the complexity and all the things, like, you know, how do you not get paralyzed when planning?
Chad White 20:29
Yeah, you really, I think you have to boil it down to the most basic problem that they all have, and you solve for that problem, you get that into people's hands, and then you see what problems still exist. I think, and you can get it into different groups of users' hands, and maybe the problems are different for the different groups, and you have to look at that particular problem across, you know, those two groups, and say, okay, we've got this problem and that problem, but they're related in, you know, in a way, and you can, you can kind of try and try and make that connection, and then you, you implement that solution. There are some problems in front of the Fluent project that are very much complicated in that way, and I don't know yet how we're going to solve them. It's going to, it's going to require some thinking, so I think also I'll add to this real quick. I think also being okay with ambiguity in those, in those in between places, before you actually have a solution that everybody's happy with, you kind of have to be okay with ambiguity, and I think that's a huge piece of product management. Is that so? Amy Joel, you're gonna say something.
Joel Matthews 21:37
Yeah, yeah, that's really helpful, Chad, because it also reminds me, and you've helped us a lot with this in Flu, and continue to is how can we decide the user group we are targeting for what we're building, and to limit choices, so saying no is a skill, and as a product manager, you, you're actively looking for things to be able to cut out and say, you know, we all want everything all the time, that that's that's just human nature, we want it all, and that's there's nothing bad in having it all for what you want to do, but it's not also not practical for what we can do with the amount of time and resources we have in front of us. So it's always a constraint management exercise there, and learning to say no is probably the hardest skill that have been really helped, Chad, with how you have brought that skill into to bear on our product management and design, and saying, okay, this is the target audience we're looking at, and we cannot try to serve these three other target audiences also at the same time. We have to say, for this quarter, let's just focus on this one target audience and their one use case and make it work for them, and once that rolls out and they're successful with it, let's expand from there, and I really like that, because you're moving iteratively, so you have quicker wins, and that keeps you in line with reality, because the world is changing always, especially with AI. The world is the way people work, how they approach things, how they tackle these problems are all changing. And so, having shorter cycles where you're putting things out and then reassessing the reality of the ground to again make another short cycle of development just keeps you grounded, anchored to what is actually useful.
Isabella Scarinzi 23:44
AI has been a hot topic for a while, and it will continue to be one. So, I always ask this question, and Chad, I'll ask you the same thing. How would you think? How would you say AI is helping the role of the product manager right now? How is it making it more effective?
Chad White 24:04
Yeah, this is this is a pretty exciting one for me, as I have gotten into it in this last less than six months. I last year I kind of, as AI was rolling in and continued to roll in, I kind of had a vision for being able to have a system where I could put the information about the product that I was building into it and have the AI kind of comb through that and be able to pull the information out of that system for say a feature that I was working on and only it's only been in this year, especially in talking to clappy and talking to several other people, giving me some ideas about how to use cloud code, and that can write files to my system, where I can, I have set up a workflow where I can drop in some meeting notes, and it will distill. A series of and I'll let Clappy describe the Dolce system, but it, that's an acronym, and each one of those has has meaning that Clappy can describe better, so I won't try, but it distills each of those out of the meeting notes, and then it will save feature potential feature ideas into the system, it saves those notes, and then I can go back to the system later and say, okay, I want to work on this feature, collect all the information that I have in my system now about that feature, and it will go back and look through all those Dolce points that were made, and it will then crunch that and put that into a requirement stock for me that I can, then you know, evaluate, is this, is this actually sound, and I'll push back against it, and ask questions, and get it to, to crunch on it for me, and then I'll take that back, I'll take that to Joel, and to the engineering manager, and I will get them to evaluate it, is this actually technically feasible is this where we're headed as far as the vision of the product, and once we, you know, we'll do some editing, we'll take it back to the AI and talk to it again, but once we're happy with that, then I can give that document to the AI again and have it create a ticket for the engineering team. If I really want to test it in a proof of concept way, I can give that ticket document that it creates to a system like Lovable or Claw Design, which I've just started delve into, and it looks really good, and I can have them create that proof of concept that I need, and then I can take that to actual users in the field and have them kick the tires and give me feedback before any engineering ever did. It didn't cost me anything except for my monthly subscription, and so AI has really had a pretty big impact, I would say, on the work that and how I work in the work that I do. Yeah, I think it's a very exciting area, I think, too, that's that's that's the impact on my work, and how I do work. We talked a little bit about draft zero and AI courses all over that, and being able to generate draft zeros, but that's more for Bible translation, and not how product management is done. But I don't want to forget that as well. It's a piece of the innovation that product management has brought into the Bible translation space as well, so I'll stop there. Somebody probably has a question.
Klappy 27:26
Well, to me, that's really exciting to hear you talk about, you know, that journey all the way to including building proof of concepts. I mean, that's you guys invited me into the Fluent team to help build proof of concepts alongside of you, right. That's why I was invited, and then I saw the work you were doing, Chad, and the questions you were asking in your openness to lean in to using AI. And so that's when we started exploring. Well, instead of me building proof of concepts for you guys, what if I started showing you the things I do with software development, you know, using AI for software development on my side of things, is that practical to you? Right, like, is this useful? And you know, you talked about the Dolce. You know, sometimes when you're working with AI, you can make up your own vocabulary that works the way you work, right? And so, like, Dolce is just like this vocabulary term that Claude Code and I came up with to encode like memory to persist for a project journal, so we can always remember what's going on from the beginning of our project to the end of the project in little project journal entries, and it's decisions, observations, learnings, constraints, handoffs, you know, it's like it encodes it, so it's called dolce, it's so silly, but that's the amazing part of AI, you can make up stuff, and it actually is useful and helpful and shareable, like it seems practical to you, like I, I didn't force you, or even like give you a training manual, and like this onboarding process, I'm just like, hey Chad, try it out, see if it's useful for you. Here's a little bit of how I use it, and then I've been pleasantly surprised to see how practical and portable the things that that I do, for you know, crazy and wild proof of concept stuff is actually practical for you on the user side in project management, and, and you know, obviously not all of it is, but the most amazing part to me is you've been able to create proof of concepts yourself. You know, we talk about tightening feedback loops in creating things and testing it on the field as quick as possible. Well, if you're able to do that and test it with the team, that's way faster than you guiding me, and what needs to be, you know, built to go test on the field, like we're tightening that loop, and you're actually able to directly interact with AI, and that doesn't mean that cuts me out of the picture. It just, it kind of just helps us sharpen each other and be more effective at what we do.
Chad White 30:08
Yeah, definitely. I've been very thankful for the interaction that we have had in the area of AI, and for the change that that has caused in the way that I work. It was not something I didn't, I hadn't envisioned it, you know, I had envisioned it last year, but I just needed a little shove and someone to walk alongside, and so I'm really grateful for that. So,
Joel Matthews 30:31
yeah, just practically the example that Chad just mentioned, I'd like to elaborate how useful it has been in using the system for building a proof of concept for flow and mobile, which we are very early on in development, but even before we handed anything on to our onto the developers to build specific features, Chad and Clappy, I was involved, they worked in building this whole pipeline of what are we really trying to do here, so starting from product management and requirements to actually creating a POC through AI, all through AI, and handing it back to the end users, so we had a couple of product managers on the field who we interacted, which had interacted with, and got feedback, and they actually even suggested going and sharing it with a few of the translators directly and getting more feedback, because on their own volition, so it's, it's exciting to see how we were able to do all of this without involving the dev team in any of it at the moment, and gain, gain all of this feedback, because otherwise this conventionally would have meant that we built this POC, which would require dev team effort, and then do the feedback process, but we're able to sidestep that requirement for the moment, and then whatever. Now we are going to ask the dev team has already gone through a full cycle of user feedback, which gets us much, much closer to what we really want on the field. So I'm really pleased and excited about how we've been able to leverage AI practically for our project so far,
Isabella Scarinzi 32:26
so we have diverse listeners from all parts of the Bible translation world, and we actually have listeners from over 50 countries that tune in, which is really exciting. So, as we wrap up these discussions, we've talked about the importance of product management and accelerating Bible translation, as well. So, Chad, what would you want translators, developers, and leaders to understand about product management, so the work can be more effective?
Chad White 32:56
Yeah, I love this question. I would say to translators, your experience is the product. When something feels clunky or it slows you down, it's not a minor complaint. That's that signal, if you will. The best thing that you can do, and this is something I always say to my users when I talk to users, is communicate it clearly and trust that it matters. I, you know, I don't want just the positive feedback, I want the negative feedback. I want to know what's broken and what's not working, and so that's that's the biggest thing that I would say to translators is they use software that we build. I would say for developers the goal isn't a feature, it's it's a translator finishing a book, so as you develop the software, every technical decision that is made connects to that. When you understand the mission, you make things, you make better calls on things that never make it into a development ticket. So, when, like, so, for example, when a choice is not obvious, ask the question, what does this mean for the person at the end of the chain, the translator, and how is this going to affect them? So that's what I would say. Keep the user in mind as a developer. And then, for leaders, product management isn't just a layer of bureaucracy between you and the work. It is the discipline of making sure that the right thing gets built in the right order with the right people in mind, I would, I would encourage leaders to invest in product management, like they invest in, say, linguistics or theological training, or things like that. The quality of the tool will shape the quality of the work. So, those are those are three things. I guess
Isabella Scarinzi 34:36
that's great, Chad. Thank you so much for sharing. If you, one of our listeners, if you have any specific questions, maybe about product management or any other Bible translation innovation topics that you would like us to address on this show, you can send them to Lab at eten dot bible, and we will answer your questions in a future episode. Chad, thank you so much for joining us. So it was a great discussion, and I will see Jill and copy at our next recording.
Chad White 35:06
Thank you for having me. The
Theophany Media Media 35:15
Bible Translation Innovation Podcast is brought to you by the E 10 Innovation Lab. This episode is edited and produced by Jake Doberins with Theophany Media. Your hosts were Joel Matthew and Christopher Clapp, with facilitation by Isabella Scarrenzi. Please subscribe on your favorite podcast platform, and we'll be with you again next month.